Hello,
The following statement works with clisp but not with gcl.
All we are doing here is defining an anonymous function
with the lambda construct and applying it to one element
with the lisp apply function:
CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
2
GCL> (apply (lambda (x) (+ x 1)) '(1))
Error: The function LAMBDA is undefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at APPLY. Type :H for Help.
Duh! The funny thing is that both CLISP and GCL like my lambda
functions when I apply them in the regular fashion:
CLISP> ((lambda (x) (+ x 1)) 3)
4
GCL> ((lambda (x) (+ x 1)) 3)
4
Now here is where both mess up:
CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
*** - EVAL/APPLY: too many arguments given to :LAMBDA
GCL> (apply (lambda (x) (+ x 1)) '(1 2 3))
Error: The function LAMBDA is undefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVALHOOK.
Backtrace: system:universal-error-handler > evalhook > APPLY
Broken at APPLY.
The output should be (2 3 4) !!!
Am I missing something?
Thanks,
Neil
"Neil Zanella" <········@garfield.cs.mun.ca> wrote in message
·············································@garfield.cs.mun.ca...
>
>
> CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
> 2
>
> GCL> (apply (lambda (x) (+ x 1)) '(1))
>
> Error: The function LAMBDA is undefined.
Try #'(lambda (x) (+ x 1))
>
> Now here is where both mess up:
>
> CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
> *** - EVAL/APPLY: too many arguments given to :LAMBDA
>
> GCL> (apply (lambda (x) (+ x 1)) '(1 2 3))
> Error: The function LAMBDA is undefined.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > evalhook > APPLY
> Broken at APPLY.
>
> The output should be (2 3 4) !!!
>
Looks like you want mapcar not apply
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
From: Kent M Pitman
Subject: Re: lambda application: clisp works sometimes, GCL just doesn't.
Date:
Message-ID: <sfw8zedsjg1.fsf@world.std.com>
Neil Zanella <········@garfield.cs.mun.ca> writes:
>
>
> Hello,
>
> The following statement works with clisp but not with gcl.
> All we are doing here is defining an anonymous function
> with the lambda construct and applying it to one element
> with the lisp apply function:
>
> CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
> 2
This is a bug. It is treating it as if you wrote
(apply (lambda (x) (+ x 1)) '(1))
and not noticing that you have given too many args.
A single-argument lambda should get a one-length list as an argument
when using apply.
> GCL> (apply (lambda (x) (+ x 1)) '(1))
>
> Error: The function LAMBDA is undefined.
This is a bug, too, but a different one. GCL is not up-to-date and does
not have all the definitions it should. In particular, lambda is supposed
to be defined as this macro:
(defmacro lambda (&rest stuff)
`#'(lambda ,@stuff))
You can perhaps add that macro to fix things. However, the other way to
win is just to explicitly put #' in front of lambda expressions in GCL.
e.g., (apply #'(lambda (x) (+ x 1)) '(1)) => 2
> Duh! The funny thing is that both CLISP and GCL like my lambda
> functions when I apply them in the regular fashion:
>
> CLISP> ((lambda (x) (+ x 1)) 3)
> 4
> GCL> ((lambda (x) (+ x 1)) 3)
> 4
>
CLISP here is being happy because you passed the correct number of args.
Also, these are not "applied" at all. This is a special-case expression
in CL called a "lambda combination" and is handled by long tradition, NOT
as you might expect, because (lambda...) is evaluating to something that is
then being applied. The operation is much more primitive. Arbitrary forms
are not permitted in the car of a form; lambda expressions are the only
non-atomic things you can put there.
> Now here is where both mess up:
>
> CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
> *** - EVAL/APPLY: too many arguments given to :LAMBDA
Again, too many args.
> GCL> (apply (lambda (x) (+ x 1)) '(1 2 3))
> Error: The function LAMBDA is undefined.
You're repeating yourself. LAMBDA is undefined as a macro.
Here you have a (lambda...) as an expression, and that only became
recently defined. In older lisps, like gcl, you have to write
(function (lambda...)) or #'(lambda ...)
> The output should be (2 3 4) !!!
No, it should not. You're thinking of MAPCAR.
> Am I missing something?
A bunch of things. But it would help to keep your examples more
consistent. You kept changing your args between examples, for example.
Also, you didn't read the documentation for GCL, which (I assume)
doesn't purport to conform to ANSI CL. So you are risking losing on a
lot of things in that. Many changes happened between CLTL (the reference
document for GCL) and ANSI CL, and you're going to trip on all of them
if you continue. It's a bad idea to start with this implementation if
you don't know what the differences are. I think you're better off
with CLISP, of the two you've chosen, though most any implementation
other than GCL will be more modern.
Kent M Pitman <······@world.std.com> writes:
> Neil Zanella <········@garfield.cs.mun.ca> writes:
>
> >
> >
> > Hello,
> >
> > The following statement works with clisp but not with gcl.
> > All we are doing here is defining an anonymous function
> > with the lambda construct and applying it to one element
> > with the lisp apply function:
> >
> > CLISP> (apply (lambda (x) (+ x 1)) '(1 2 3))
> > 2
>
> This is a bug.
I'd recommend to the OP that he get a newer CLISP version -- this
behaved correctly (error) in the oldest CLISP I have (March 2000)
[...]
> > GCL> (apply (lambda (x) (+ x 1)) '(1))
> >
> > Error: The function LAMBDA is undefined.
>
> This is a bug, too, but a different one. GCL is not up-to-date and does
> not have all the definitions it should.
And also presumably an old one. My copy of gcl gets this right.
I am running the latest version of clisp (version 2.27)
as well as gcl version 2.3. I have heared that the reason
the following code works with the clisp interpreter ...
CLISP> (funcall (lambda (x) (+ x 1)) 1)
2
CLISP> (apply (lambda (x) (+ x 1)) '(1))
2
CLISP> (mapcar (lambda (x) (+ x 1)) '(1 2 3))
(2 3 4)
but not with the gcl interpreter is that the clisp interpreter
implements the ANSI Common Lisp standard whereas the gcl interpreter
implements the older CLtL standard which is somewhat incompatible.
In order to get the above code to work with both interpreters one
must use either function or its equivalent shorthand notation '#
in front of the lambda definitions. Here is the code that works
with both interpreters:
CLISP OR GCL> (funcall (function (lambda (x) (+ x 1))) 1)
2
CLISP OR GCL> (apply (function (lambda (x) (+ x 1))) '(1))
2
CLISP OR GCL> (mapcar (function (lambda (x) (+ x 1))) '(1 2 3))
(2 3 4)
Perhaps newer versions of GCL get the former right as well but
I was unable to install the latest version of GCL on Red Hat 7.1:
<http://www.ma.utexas.edu/users/wfs/pub/gcl/gcl-2.4.0.tgz>
I would be interested in knowing whether the CLISP only function
calls listed above work with this newer version of gcl for those
of you which have installed it correctly presumably on some other
platform.
Thanks,
Neil
Neil Zanella <········@garfield.cs.mun.ca> writes:
> I am running the latest version of clisp (version 2.27)
> as well as gcl version 2.3. I have heared that the reason
> the following code works with the clisp interpreter ...
>
> CLISP> (funcall (lambda (x) (+ x 1)) 1)
> 2
> CLISP> (apply (lambda (x) (+ x 1)) '(1))
> 2
> CLISP> (mapcar (lambda (x) (+ x 1)) '(1 2 3))
> (2 3 4)
>
> but not with the gcl interpreter is that the clisp interpreter
> implements the ANSI Common Lisp standard whereas the gcl interpreter
> implements the older CLtL standard which is somewhat incompatible.
> In order to get the above code to work with both interpreters one
> must use either function or its equivalent shorthand notation '#
> in front of the lambda definitions. Here is the code that works
> with both interpreters:
Yes. Before he died, the maintainer had been trying to move GCL to
implement a subset of ANSI CL, so newer versions have, among other
things, lambda defined to sharp-quote itself. Pretty much, GCL is
CLTL1, with some of the niceties from ANSI CL thrown in. The result
is a perfectly wonderful language that rates in my top 5 that I'd want
to use, but ANSI CL is higher :)
> Perhaps newer versions of GCL get the former right as well but
> I was unable to install the latest version of GCL on Red Hat 7.1:
> <http://www.ma.utexas.edu/users/wfs/pub/gcl/gcl-2.4.0.tgz>
>
> I would be interested in knowing whether the CLISP only function
> calls listed above work with this newer version of gcl for those
> of you which have installed it correctly presumably on some other
> platform.
Yep, (lambda ...) evaluates to (function (lambda ...)) in newer
versions (not sure where that changed since I don't use GCL too
often).
For what it's worth, the "other platform" that I'm using is Debian.
Normally I don't engage in much distro evangelization, but Debian is
head and shoulders above the other linux distros in terms of support
for lisp environments.
On 14 Oct 2001, Thomas F. Burdick wrote:
> Yep, (lambda ...) evaluates to (function (lambda ...)) in newer
> versions (not sure where that changed since I don't use GCL too
> often).
I would be interested in knowing the gcl version which produced the
above mentioned result. Also, out of curiosity, do you know where I
can find the CLTL standards.
> For what it's worth, the "other platform" that I'm using is Debian.
> Normally I don't engage in much distro evangelization, but Debian is
> head and shoulders above the other linux distros in terms of support
> for lisp environments.
I must admit that Red Hat 7.1 does not seem to include any common lisp
stuff except for possibly some emacs lisp things which I have yet to
look into.
Thanks,
Neil
Neil Zanella <········@garfield.cs.mun.ca> writes:
> On 14 Oct 2001, Thomas F. Burdick wrote:
>
> > Yep, (lambda ...) evaluates to (function (lambda ...)) in newer
> > versions (not sure where that changed since I don't use GCL too
> > often).
>
> I would be interested in knowing the gcl version which produced the
> above mentioned result. Also, out of curiosity, do you know where I
> can find the CLTL standards.
It was gcl version 2.4.0, I believe. However, I'd reccomend sticking
to CLISP and the ANSI defined language unless you have a specific
reason not to. You can find the webbed version of "Common Lisp the
Language, 2d ed.", pretty easily with google. It's a marked up
edition of the first edition, so you can see both the original
definition, and the changes made from it. The language it describes
is no ANSI CL -- it's similar, but it's got a little more here and a
little less there, and is just a bit different back there.
You can find the description of ANSI CL by doing a search for "Common
Lisp Hyperspec".
From: Kent M Pitman
Subject: Re: lambda application: clisp is OK, older gcls are not ANSI Common Lisp
Date:
Message-ID: <sfwn12tcppl.fsf@world.std.com>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Yep, (lambda ...) evaluates to (function (lambda ...)) in newer
^^^^^^^^^
You mean "expands" here, of course.
> versions (not sure where that changed since I don't use GCL too
> often).
Kent M Pitman <······@world.std.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Yep, (lambda ...) evaluates to (function (lambda ...)) in newer
> ^^^^^^^^^
> You mean "expands" here, of course.
*blush* -- yes, naturally, it expands to (function (lambda ...)),
which evaluates to a function object. I knew what I meant :)
>>>>> "Thomas" == Thomas F Burdick <···@conquest.OCF.Berkeley.EDU> writes:
Thomas> Yes. Before he died, the maintainer had been trying to
Bill Schelter is dead? When and how did this happen? :(
--
"His power lies apparently in his ability to choose incompetent
enemies." - Crow T. Robot, MST3K, "Prince of Space"
········@irtnog.org writes:
> >>>>> "Thomas" == Thomas F Burdick <···@conquest.OCF.Berkeley.EDU> writes:
>
> Thomas> Yes. Before he died, the maintainer had been trying to
>
> Bill Schelter is dead? When and how did this happen? :(
See the messages on the Maxima mailing lists:
http://www.math.utexas.edu/pipermail/maxima/2001/000264.html
http://www.math.utexas.edu/pipermail/maxima/2001/000267.html
Yours, Nicolas.