From: Erik H. <eh...@gm...> - 2009-04-12 13:11:00
|
On Sat, Apr 11, 2009 at 9:15 PM, Logan O'Sullivan Bruns <lo...@ge...> wrote: > Hi, > > I was wondering if anyone had gotten Richard Waters's series package > (http://series.sourceforge.net) to work with Armed Bear Common Lisp? > It would appear to depend upon compiler-let which ABCL doesn't seem to > support. (I suppose because it isn't part of ANSI common lisp.) The fact that COMPILER-LET isn't part of the spec doesn't help. However, ABCL implicitly contains a MACROEXPAND-ALL facility, meaning that it would be almost trivial to create the functionality both for the compiler and the interpreter as described by http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Issues/iss066-writeup.html > Is there a known workaround for this? Perhaps a patch to the series > package or an extension to ABCL? There's currently no workaround, but I'd be willing to create the extension described in the URL above. In which package does SERIES expect the COMPILER-LET symbol to exist? In the LISP package? If so, I believe CLtL2 software may be expecting many of the CL symbols to exist in the LISP package. Do you know if this is true? (I know AP5 had some expectations that way.) Ville, Douglas, others: opinions on creating LISP, adding all CL symbols to it and adding COMPILER-LET as defined by the hyperspec issue referenced above? Bye, Erik. |
From: Ville V. <vil...@gm...> - 2009-04-12 13:28:41
|
> Ville, Douglas, others: opinions on creating LISP, adding all CL > symbols to it and adding COMPILER-LET as defined by the hyperspec > issue referenced above? I have no objections, but I slightly wonder why such LISP package is used by applications, LISP is AFAIK not a standards-supported nickname for COMMON-LISP or COMMON-LISP-USER packages. Anyhow, if it is commonly used, I'm all for supporting it. |
From: Erik H. <eh...@gm...> - 2009-04-12 13:40:22
|
On Sun, Apr 12, 2009 at 3:28 PM, Ville Voutilainen <vil...@gm...> wrote: >> Ville, Douglas, others: opinions on creating LISP, adding all CL >> symbols to it and adding COMPILER-LET as defined by the hyperspec >> issue referenced above? > > I have no objections, but I slightly wonder why such LISP package is used > by applications, LISP is AFAIK not a standards-supported nickname for > COMMON-LISP > or COMMON-LISP-USER packages. Anyhow, if it is commonly used, I'm all > for supporting it. AFAIK, the LISP package is the COMMON-LISP equivalent of CLtL2. That's why some legacy applications may (wrongly) still depend on it. Unfortunately, SERIES doesn't seem to be ported to CL, instead being developed in CLtL2. Possibly because of their use of COMPILER-LET. Bye, Erik. |
From: Chun T. (binghe) <bin...@gm...> - 2009-04-12 15:27:33
|
Hi, ABCL I think a modern CL implementation like ABCL shouldn't create LISP (and USER) package anymore. If you want to support some CLTL2 operators, I'll suggest using a new package "CLTL2", just like the "SB-CLTL2" package in SBCL. There're other useful features exist in CLTL2 but not exist in ANSI Common Lisp, like first-class environment support: AUGMENT- ENVIRONMENT. If ABCL wants to support them in the future, the new "CLTL2" package will also be a good place. --binghe On 2009-4-12, at 21:31, Erik Huelsmann wrote: > On Sun, Apr 12, 2009 at 3:28 PM, Ville Voutilainen > <vil...@gm...> wrote: >>> Ville, Douglas, others: opinions on creating LISP, adding all CL >>> symbols to it and adding COMPILER-LET as defined by the hyperspec >>> issue referenced above? >> >> I have no objections, but I slightly wonder why such LISP package >> is used >> by applications, LISP is AFAIK not a standards-supported nickname for >> COMMON-LISP >> or COMMON-LISP-USER packages. Anyhow, if it is commonly used, I'm all >> for supporting it. > > AFAIK, the LISP package is the COMMON-LISP equivalent of CLtL2. That's > why some legacy applications may (wrongly) still depend on it. > > Unfortunately, SERIES doesn't seem to be ported to CL, instead being > developed in CLtL2. Possibly because of their use of COMPILER-LET. > > > Bye, > > Erik. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
From: Ville V. <vil...@gm...> - 2009-04-12 15:48:18
|
On Sun, Apr 12, 2009 at 6:26 PM, Chun Tian (binghe) <bin...@gm...> wrote: > I think a modern CL implementation like ABCL shouldn't create LISP (and > USER) package anymore. We want to provide an implementation on which existing code runs, standard-compliance is less important. If there areapplications that people use, and people want to run those applications on abcl (without modifying the applications themselves), I'm all for adding such compatibility. |
From: <don...@is...> - 2009-04-12 18:40:22
|
> We want to provide an implementation on which existing code runs, > standard-compliance > is less important. If there areapplications that people use, and > people want to run those > applications on abcl (without modifying the applications themselves), > I'm all for adding such > compatibility. You might consider the approach in clisp where command line arguments select compatibility modes, e.g., one for maximum ansii compliance, which is not the default. |
From: Ville V. <vil...@gm...> - 2009-04-12 19:11:12
|
On Sun, Apr 12, 2009 at 9:40 PM, Don Cohen <don...@is...> wrote: > You might consider the approach in clisp where command line arguments > select compatibility modes, e.g., one for maximum ansii compliance, > which is not the default. We would need arguments for both the compiler and for the interpreter, that's not as easy as it sounds on the surface. |