Re: CDR for Package-Local Nicknames [Feedback Request]

2024-07-13 Thread Marco Antoniotti
I see your point, Alas *import FooBarBaz as FBB* is what people have gotten used to. Cheers Marco On Sat, Jul 13, 2024 at 5:59 PM Pascal Bourguignon wrote: > > > > On 13 Jul 2024, at 16:53, Marco Antoniotti > wrote: > > > > Sorry. I was so caught up coloriz

Re: CDR for Package-Local Nicknames [Feedback Request]

2024-07-13 Thread Marco Antoniotti
Sorry. I was so caught up colorizing that I messed it up. I meant USE-PACKAGE Marco Antoniotti https://dcb.disco.unimib.it On Sat, 13 Jul 2024 at 16:47, Pascal Bourguignon wrote: > > > On 13 Jul 2024, at 11:49, Marco Antoniotti > wrote: > > Hi > > Thanks for the wri

Re: CDR for Package-Local Nicknames [Feedback Request]

2024-07-13 Thread Marco Antoniotti
th a compatibility layer, etc). I've seen people describe > doing that with :USE, and package local nicknames should support it as > well, and more safely in cases where any of those packages might > change over time. > -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

CLAST reworked

2024-06-26 Thread Marco Antoniotti
Hi just in case you may be interested, I updated the CLAST documentation (and posted a blog post on https://within-parens.blogspot.com/2024/06/clast-reworked.html) All the best Marco -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca

CLAST: major refactoring

2024-06-23 Thread Marco Antoniotti
Probably also ECL. The naughty Java crowd giving us ABCL instead needs to do some work (naughty, naughty, naughty)! People working on other implementations, please drop me a line. https://clast.sf.net (The documentation is not up to date, but that's minor) Enjoy -- Marco Antoni

Re: DEFTYPE and SATISFIES

2024-02-22 Thread Marco Antoniotti
st curries one argument and MSB-TEST does the > > check, taking two arguments, the second being the object to typep > > (details irrelevant; trust me: it works). > > > > I know: done too much Haskell recently. > > > > MA > > > > On Wed, Feb 21, 2024 at 11:45 

Re: DEFTYPE and SATISFIES

2024-02-22 Thread Marco Antoniotti
non wrote: > Le 21/02/2024 à 22:10, Marco Antoniotti a écrit : > > Hi > > > > I just stumbled upon this and I need confirmation. > > > > You cannot do anything like this, can you? > > > > *(defstruct foo x)* > > * > > * > > *(deft

Re: DEFTYPE and SATISFIES

2024-02-21 Thread Marco Antoniotti
... ok. Sorry. CURRY does it. MA On Wed, Feb 21, 2024 at 10:10 PM Marco Antoniotti < marco.antonio...@unimib.it> wrote: > Hi > > I just stumbled upon this and I need confirmation. > > You cannot do anything like this, can you? > > *(defstruct foo x)* &g

DEFTYPE and SATISFIES

2024-02-21 Thread Marco Antoniotti
-x-p*, is there? All the best MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Academic endian question

2024-02-04 Thread Marco Antoniotti
) All the best MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Re: Help with bit bashing code: differences between C and CL

2023-11-12 Thread Marco Antoniotti
loor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0 > > which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output > has exactly 16 significant digits, while the clang output has 20. > > The actual correct digits seem to be > > (ash (expt 10 52) -52) > > which eva

Re: Help with bit bashing code: differences between C and CL

2023-11-12 Thread Marco Antoniotti
e C library prints some extra digits that > are not needed. > > -- > Martin Simmons > LispWorks Ltd > http://www.lispworks.com/ > > > > >>>>> On Fri, 10 Nov 2023 09:55:38 +0100, Marco Antoniotti said: > > > > Hi > > > > Thanks Pascal. &

Re: Help with bit bashing code: differences between C and CL

2023-11-10 Thread Marco Antoniotti
digits, while the clang output has 20. > > The actual correct digits seem to be > > (ash (expt 10 52) -52) > > which evaluates to > > 2220446049250313080847263336181640625. > > > > > > On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti a

Re: Help with bit bashing code: differences between C and CL

2023-11-10 Thread Marco Antoniotti
MA On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at informatimago dot com) wrote: > > > On 9 Nov 2023, at 21:21, Marco Antoniotti > wrote: > > > > > > From the start, it looks like the ulp is more precise in C: > > > sbcl: 2.220446049250

Re: Help with bit bashing code: differences between C and CL

2023-11-09 Thread Marco Antoniotti
ults starting > at j = 21… > > > > Lisp: j = 21; ss = 0.00028959847986698150 > > C: j = 21; ss = 0.00028959847986698151 > > > > FWIW … > > > > Best, > >Frank > > > > *Von: * im Auftrag von "Marco Antoniotti > (as marco dot anton

Help with bit bashing code: differences between C and CL

2023-11-09 Thread Marco Antoniotti
ang version 15.0.0 (clang-1500.0.40.1) If you run the code, you will see that the discrepancy appears at 'j = 14' in the loop. What gives? Thanks Marco -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unim

Re: Common Lisp Transformer Libraries

2023-08-11 Thread Marco Antoniotti
Hi Burton no. I have not heard of anything similar, except maybe from Mark Watson (who should be on these lists - markwatson.com). I became interested in them as well. In any case, the issue is whether you are interested in a CL implementation or a binding to this or that C/C++ library (yeah! I

Re: Numpy and Common Lisp?

2023-04-12 Thread Marco Antoniotti
"if it's there I > will start using it right away." > > | I guess the trait valuation is that I would like something that I > | could use instead of numpy, so quite portable (although if it only > | worked in SBCL, that would be fine), implementation effort:

Re: Numpy and Common Lisp?

2023-04-12 Thread Marco Antoniotti
Hey Antoni. A lot of Common Lisp actually comes from PL/I :) :) And getting an APL capable 3270 emulator is easily done :) :) :) On Wed, Apr 12, 2023 at 8:37 PM Antoni Grzymała wrote: > Isn’t april (somebody mentioned that already) a high quality > implementation of such a library? I understan

Re: Numpy and Common Lisp?

2023-04-12 Thread Marco Antoniotti
on Lisp professionals > Subject: Re: Numpy and Common Lisp? > > There’s cl-ana, which may be a useful substitute in some cases… or april, > possibly. > > cliki.net > > cl-ana > <https://www.cliki.net/cl-ana> > cliki.net > > april > <https://www.cli

Re: Numpy and Common Lisp?

2023-04-10 Thread Marco Antoniotti
Hi Michael I am all for it. But, as I said, I am an academic (and a cat). Should we (as in "a bunch of common lispers", most of whom with day jobs) want to do something like that, how would you want to proceed? Note that I have been part of many past failures. All the best Marco On Tue, Apr

Re: Numpy and Common Lisp?

2023-04-10 Thread Marco Antoniotti
IMHO, it'd be easier and effective to band up together and FIRST write a proper API specification and THEN implement it in CL. But Common Lispers are like academics: the "herding cats" applies. Cheers Marco PS I am a Common Lisper AND an academic. You know what I mean... On Mon, Apr 10, 202

Re: IRC lisp channels?

2021-12-18 Thread Marco Antoniotti
ialects > > #clim for clim development > > #abcl, #ccl, #ecl, #sbcl, #mezzano, #sicl for implementation devs. > > and #lispcafe for random ramblings. > > > > -- > __Pascal Bourguignon__ > > -- Marco Antoniotti, Professor tel. +3

IRC lisp channels?

2021-12-18 Thread Marco Antoniotti
Hi I guess this is mostly for phoe... What is the status of the IRC channels? I think I lost some bits during the year. Also, anybody interested in a Discord channel or a groups.io group? Happy holidays (especially Festivus) -- Marco Antoniotti, Professor tel. +39

Re: Scheme like question

2021-12-14 Thread Marco Antoniotti
> (defun integral (integrand initial-value dt) > (let ((int nil)) > (setf int (cons-stream initial-value >(add-streams (scale-stream integrand dt) > int) > > > -- > Vibhu > > -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Scheme like question

2021-12-13 Thread Marco Antoniotti
tegrand dt) int))) int) The question is how you'd rendered it in Common Lisp or how you would provide some macrology to mimic the inner define. I know this has been asked before... I am sure somebody knows the answer. All the best -- Marco Antoni

Re: Pattern, Abstract Factory / Factory

2021-02-07 Thread Marco Antoniotti
Ooooh you are s evil Pascal :) :) :) On Sun, Feb 7, 2021 at 11:29 AM Pascal Bourguignon wrote: > Le 07/02/2021 à 10:10, Marco Antoniotti a écrit : > > ... and I can always CHANGE-CLASS, can't I? > > Of course. There are a lot of features of CL that renders mo

Re: Pattern, Abstract Factory / Factory

2021-02-07 Thread Marco Antoniotti
>> > > You don't. You have a dependency on the name of a class. The name could > refer to two entirely different classes between invocations of FIND-CLASS. > The name could also come from an external source. Thus, this is purely a > run-time dependency and it would be q

Re: Pattern, Abstract Factory / Factory

2021-02-07 Thread Marco Antoniotti
; ;; Notably if the client wants the user to use another used class: > > (defclass variant-used (used) >()) > (defmethod used-stuff ((self variant-used)) >'variant-stuff) > > (defmethod create-user ((self client)) >;; only the client needs to be changed; the user class won't know >;; the difference: >(make-instance 'user :used (make-instance 'variant-used))) > > > -- > __Pascal Bourguignon__ > > -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Re: Pattern, Abstract Factory / Factory

2021-02-06 Thread Marco Antoniotti
t it, too, inversion of control. > > It allows you to create something without having to know the concrete > type and without having to have a source dependency on it. > > In Common Lisp this could be solved easily by just separating a protocol > from the implementation, maybe in s

Re: Another (stupid) question: "find first set" (or "find first zero")

2021-02-02 Thread Marco Antoniotti
Thank you Pascal great pointer. I was unaware of this book. All the best Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Re: Another (stupid) question: "find first set" (or "find first zero")

2021-02-01 Thread Marco Antoniotti
"Duh again", in the sense that I was stupid (again!) Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Re: Another (stupid) question: "find first set" (or "find first zero")

2021-02-01 Thread Marco Antoniotti
Duh again! MA On Mon, Feb 1, 2021 at 7:47 PM Pascal Bourguignon wrote: > Le 01/02/2021 à 09:45, Marco Antoniotti a écrit : > > Duh! > > What? > > (1- (integer-length x)) is not ffs. > >76543 10 >v vv > #b11010100 > ^ > 2 &

Re: Another (stupid) question: "find first set" (or "find first zero")

2021-02-01 Thread Marco Antoniotti
Duh! On Mon, Feb 1, 2021 at 9:42 AM d...@refined-audiometrics.com < d...@refined-audiometrics.com> wrote: > (1- (integer-length x)) > > > On Feb 1, 2021, at 1:24 AM, Marco Antoniotti > wrote: > > Hi > > I am wasti devoting some time to recreation

Another (stupid) question: "find first set" (or "find first zero")

2021-02-01 Thread Marco Antoniotti
ideas? Note that it appears that most HW does have an instruction to do that directly. Find first set - Wikipedia <https://en.wikipedia.org/wiki/Find_first_set> Thanks Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 204

Re: Questions about complexity of some functions in various implementations.

2021-01-23 Thread Marco Antoniotti
Right. Yep. The question was stupid. Sorry. MA On Sat, Jan 23, 2021 at 6:35 PM Elias Mårtenson wrote: > On Sun, 24 Jan 2021 at 00:40, Marco Antoniotti > wrote: > >> Hello everybody >> >> I remember from the trenches that LW implementation of INTERSECTION

Questions about complexity of some functions in various implementations.

2021-01-23 Thread Marco Antoniotti
-IF for VECTOR inputs in various implementations? That is, does anybody know whether these functions have at least O(lg n) time complexity in any of the implementations out there? All the best Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università

Re: In CLOS, instance remorphing considered useless in practice?

2020-12-09 Thread Marco Antoniotti
u were going to bring the environment API in "Very Soon Now" (tm). I have not checked the latest and greatest ABCL, but is it in now? :) :) :) On Wed, Dec 9, 2020 at 12:07 PM Marco Antoniotti wrote: > Jean-Claude > > the point is that CLOS is not a "library", although it was

Re: In CLOS, instance remorphing considered useless in practice?

2020-12-09 Thread Marco Antoniotti
gt;> the spot. >> >> - nick >> > > > BTW, I just remembered that PCL (that venerable demonstration > implementation of CLOS) contains all the machinery needed to implement that > identity preservation feature as application level code expressed in CLTL1 > compat

Re: In CLOS, instance remorphing considered useless in practice?

2020-12-09 Thread Marco Antoniotti
we were dropping CLTL1 version of Common Lisp on top of them before > our application code. > So, no CLOS. That came later... > > >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• >> http://fare.tunes.org >> Taxonomy is the death of science — A.

Re: Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus

2020-12-03 Thread Marco Antoniotti
Don't the latest incarnations of ECL use the Bohem GC? Just asking... MA Get Outlook for Android From: pro on behalf of Martin Cracauer Sent: Thursday, December 3, 2020 6:25:50 PM To: Discussion list for Common Lisp professionals Subje

Re: Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus

2020-12-02 Thread Marco Antoniotti
ating an approachable pathway to IT >>>> careers for anyone really, but in the spirit of today one focused on >>>> creating career opportunities for >>>> > African Americans. >>>> > >>>> > The idea would be a code camp developed around algorithmic generation >>>> of music. I know nothing about music theory, except that there is prolly >>>> enough there to introduce >>>> > most if not all fundamental programming concepts. >>>> > >>>> > For those campers that accidentally get hooked on programming itself, >>>> which is how many of us ended up in IT careers, away they go! >>>> > >>>> > The idea is to: >>>> > * use music as the hook; >>>> > * defer as long as possible the annoying things about programming >>>> (I am looking at you, node.js); >>>> > * part of that ^^^ will be using a powerful language with the >>>> parentheses in the right place, prolly ClojureScript since that could run >>>> where JS runs; >>>> > * keep programming as the focus, as tempting as the music will be. >>>> Sonic Pi comes with all sorts of built-in sound capabilities, but we want >>>> to develop those in the >>>> > code camp; >>>> > * tailor the program to specific musical genres, to maximize the >>>> musical hook. >>>> > I am dropping this here since I know many Common Lispers have a >>>> strong musical bent. My questions are: >>>> > * Could we use CL instead? I do think this almost has to be a web >>>> app, perhaps even mobile. Hmmm, we could CL-ify CLJS with sufficent clever >>>> macrology. >>>> > * What do you think? Can a solid programming fundamentals course be >>>> expressed in music theory? Hint: HTTP is not a programming fundamental. >>>> > * If there is any interest, what would be a good place for an >>>> ongoing discussion? Google groups? >>>> > Ideas, comments, suggestions all welcome. >>>> > >>>> > -hk >>>> > >>>> > >>>> > >>>> > -- >>>> > Kenneth Tilton >>>> > http://tiltontec.com/ >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Kenneth Tilton >>>> > http://tiltontec.com/ >>>> > >>>> > >>>> > >>>> > -- >>>> > Kenneth Tilton >>>> > http://tiltontec.com/ >>>> > >>>> > >>> >>> >>> >>> -- >>> Kenneth Tilton >>> http://tiltontec.com/ >>> >> >> -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

RE: Re: Hi

2020-05-11 Thread Marco Antoniotti
I don’t teach it to students.  I inflict it 😊 😊 😊 In any case, it would be very interesting to compare notes, Zbyszek. Cheers Marco AntoniottiDISCo, Università degli Studi di Milano-Bicocca+39 02 6448 7901bimib.disco.unimib.it  From: Zbyszek JurkiewiczSent: Monday, May 11, 2020 08:37To: pro@common-

RE: Re: Hi

2020-05-08 Thread Marco Antoniotti
Hello Still an amateur here 😊 Marco AntoniottiDISCo, Università degli Studi di Milano-Bicocca+39 02 6448 7901bimib.disco.unimib.it  From: Luís OliveiraSent: Friday, May 8, 2020 11:09To: Discussion list for Common Lisp professionalsSubject: Re: Hi On Fri, 8 May 2020 at 08:33, Daniel Kochmański wrot

Re: CDR-14 and optional modules

2019-06-01 Thread Marco Antoniotti
implementation provides > a loadable module to support a CDR? Should the feature be always present > or only appear when the module is loaded? >What are the opinions? > >Thank you, good bye > Michael Raskin > > > -- Marco Antoniotti

Re: [pro] What was wrong with environments as in CLTL2 pp. 207-214?

2012-12-14 Thread Marco Antoniotti
was wrong with this part of the spec > and motivated its removal. > > Cheers, > > Jean-Claude Beaudoin > > ___ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Mar

Re: [pro] [Q] introspecting setf expanders

2012-10-09 Thread Marco Antoniotti
_ >> pro mailing list >> pro@common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro > > ___ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro --

Re: [pro] [Q] unicode support

2012-09-26 Thread Marco Antoniotti
mon-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Marco Antoniotti, Associate Professor tel.+39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Pl

Re: [pro] Looking for comments/corrections on Lisp Doc-Generation Tool Review

2012-09-25 Thread Marco Antoniotti
.tunes.org >> No man would listen to you talk if he didn't know it was his turn next. >> — Edgar Watson Howe >> >> ___ >> pro mailing list >> pro@common-lisp.net >> http://lists.common-lisp.net/

Re: [pro] Default behavior of standard output streams

2012-05-22 Thread Marco Antoniotti
n the file in > cases #2 and #3. > > > I'm ready to fill in bug reports for the last 6 compilers, but are these > really bugs? I'm convinced that it is for stderr, but it may be arguable > for *query-io*. > > WDYT? > I think this is the usual story. Beha

Re: [pro] #; comments...

2012-05-09 Thread Marco Antoniotti
ad to vote on "what sort of CDR should Pascal Costanza > write", I would vote on something CLOS or MOP related... :)) > > ___ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Mar

Re: [pro] #; comments...

2012-05-06 Thread Marco Antoniotti
-- > Pascal Costanza > > > > > _______ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Marco Antoniotti, Associate Professor tel.+39 - 02 64

Re: [pro] [Q] naming convention

2012-04-04 Thread Marco Antoniotti
lated. > > Scientific site: http://www.lrde.epita.fr/~didier > Music (Jazz) site: http://www.didierverna.com > > ___ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Marco Anton

[pro] ELS 2012, Zadar, Croatia

2012-02-01 Thread Marco Antoniotti
12: acceptance results April 30th 2012: Conference opens Program Commitee. Chair: Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY Local organizers: Damir Cavar, Eastern Michigan University Franjo Pehar, University of Zadar Damir Kero, University of Zada

[pro] [ELS 2012] European Lisp Symposium 2012, Zadar, Croatia; call for papers

2011-11-17 Thread Marco Antoniotti
2012 Conference opens Program Commitee. Chair: Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY Local organizers: • Damir Ćavar, Eastern Michigan University • Franjo Pehar, University of Zadar • Damir Kero, University of Zadar Members:

[pro] [ELS 2012] European Lisp Symposium 2012, Zadar, Croatia; call for papers

2011-11-17 Thread Marco Antoniotti
2012 Conference opens Program Commitee. Chair: Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY Local organizers: • Damir Ćavar, Eastern Michigan University • Franjo Pehar, University of Zadar • Damir Kero, University of Zadar Members:

[pro] Test again: please disregard....

2011-09-19 Thread Marco Antoniotti
Sorry -- Marco Antoniotti, Associate Professor tel.+39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore

Re: [pro] Lisp and DSLs

2011-07-22 Thread Marco Antoniotti
s of > their own. However, their 10 years CL experience to my 5 (and their far > deeper stats familiarity) would certainly have helped here. > > -Daniel -- Marco Antoniotti, Associate Professor tel.+39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14

Re: [pro] Lisp and DSLs

2011-07-21 Thread Marco Antoniotti
t; http://users.telenet.be/stes/compiler.html > (objc-3.2.11.tar.gz) > > > -- > __Pascal Bourguignon__ http://www.informatimago.com/ > A bad day in () is better than a good day in {}. > > > _______ > pro m

Re: [pro] Lisp and DSLs

2011-07-21 Thread Marco Antoniotti
der to do in > other languages. > ___ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Marco Antoniotti, Associate Professor tel.+39 - 02 64 48 7

Re: [pro] Lisp and DSLs

2011-07-20 Thread Marco Antoniotti
me semantics, including very non-linear ones, e.g. PAIP prolog. > > - Prolog provides an simple way to build parsers, if efficiency is not of > utmost concern. A number of prologs are available to CL programmers, so one > can have the best of both worlds. [I use paip prolog to parse

Re: [pro] why :key arguments?

2011-07-05 Thread Marco Antoniotti
On Jul 5, 2011, at 11:51 , Tamas Papp wrote: > I am very happy to learn about these things. Currently I am working > on the algorithms and my main concern is to ensure correctness; speed > is secondary at this point, but even though I am not optimizing, I > want to keep my code optimizable later

Re: [pro] "fhash"

2011-06-14 Thread Marco Antoniotti
Java the naming reflects the separation between abstraction and implementation. AFAIU, clojure does not quite do this and neither does Python. I would advocate settling down on a Java-esque nomenclature with MAP or DICTIONARY as "names" for the abstraction and with different names

Re: [pro] Lisp 2's and function values.

2011-06-04 Thread Marco Antoniotti
On May 26, 2011, at 18:32 , Pascal Costanza wrote: > > On 25 May 2011, at 21:40, Marco Antoniotti wrote: > >> Hi >> >> I don't think there is a reasonable objection to forbid a form like >> >> ((returns-something-funcallable arg1 arg2 ..

Re: [pro] Lisp 2's and function values.

2011-05-26 Thread Marco Antoniotti
On May 25, 2011, at 23:05 , Alessio Stalla wrote: > On Wed, May 25, 2011 at 9:40 PM, Marco Antoniotti > wrote: >> Hi >> I don't think there is a reasonable objection to forbid a form like >> ((returns-something-funcallable arg1 arg2 ... argN) 1 2 3 ... N) >>

Re: [pro] Lisp 2's and function values.

2011-05-25 Thread Marco Antoniotti
) ...)) > (bar (lambda (arg ...) ...))) > (foo ...) > (funcall bar ...)) > > > and flet/labels would transform into a generalized let binding. > > This would make the standard transformation of let -> function call a little > problematic, however. >