I have been trying to learn some lisp. I have had some experience in
scheme, which is probably why I even got disturbed by that which is
the source of my question.
Playing around with the age old bank-account example I did something
equivalent to
(defun make-adder (x) (lambda (y) (+ x y)))
((make-adder 1) 1)
and of course, I got an error. What I mean to do here is done by
using funcall. This is part of that 1-namespace vs 2-namespace
issue, which divides scheme and lisp, I know.
However, I can do
((lambda (y) (+ 1 y)) 1)
without having to use funcall, though doing
(funcall (lambda (y) (+ 1 y)) 1)
works too.
The reason seems to come down to a place in the CL spec called
3.1.2.1.2 which says that the car of the s-exp to be interpreted must
be a special form, a macro, a symbol or a lambda expression.
http://www.lispworks.com/reference/HyperSpec/Body/03_abab.htm
When evaluated, these two things look nearly the same:
[2]> (lambda (y) (+ 1 y))
#<CLOSURE :LAMBDA (Y) (+ 1 Y)>
[3]> (make-adder 1)
#<CLOSURE :LAMBDA (Y) (+ X Y)>
Yet, upon substitution into an s-exp, they can do different things.
Of course, this tells me that evaluation in the car position is not
the same as evaluation of the arguments, which is to be expected
from the wording of 3.1.2.1.2. Still it is disconcerting.
I guess that 3.1.2.1.2 allows lambdas and no other expressions
because either:
1) there is some good reason to allow lambda expressions in the car.
2) there is some good reason to disallow arbitrary function-returning
expressions in the car.
Which is it and why?
I read some of the past articles on this group about 3.1.2.1.2 and
did not see this issue discussed.
Thank you,
-r
--
Ross A. Lippert
M.I.T., Department of Mathematics
Building 2, Room 335 Voice (617) 253-7905
77 Massachusetts Avenue FAX (617) 253-4358
Cambridge, MA 02139-4307 e-mail: ·······@math.mit.edu
On Mon, Aug 23, 2004 at 02:57:42PM -0400, Ross Lippert wrote:
> Yet, upon substitution into an s-exp, they can do different things.
> Of course, this tells me that evaluation in the car position is not
> the same as evaluation of the arguments, which is to be expected
> from the wording of 3.1.2.1.2.
You hit the nail on the head. The car position is not evaluated in a
form to be evaluated. I think this is the most confusing part to former
Schemers.
> I guess that 3.1.2.1.2 allows lambdas and no other expressions
> because either:
> 1) there is some good reason to allow lambda expressions in the car.
> 2) there is some good reason to disallow arbitrary function-returning
> expressions in the car.
I think that an envisioned extension was compound function names, which
would have conflicted badly with evaluation of arbitrary
function-returning expressions in the car position. A lambda expression
could be considered as a `compound function name' which names itself,
plus it gives compilers an easy opportunity for a simple open-coding
optimization. It won't cause a conflict, because implementation-defined
compound function names would not use the symbol CL:LAMBDA.
--
;;;; Matthew Danish -- user: mrd domain: cmu.edu
;;;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Mon, Aug 23, 2004 at 02:57:42PM -0400, Ross Lippert wrote:
>> [...]
> [...]
>> I guess that 3.1.2.1.2 allows lambdas and no other expressions
>> because either:
>> 1) there is some good reason to allow lambda expressions in the car.
>> 2) there is some good reason to disallow arbitrary function-returning
>> expressions in the car.
>
> I think that an envisioned extension was compound function names, which
> would have conflicted badly with evaluation of arbitrary
> function-returning expressions in the car position. A lambda expression
> could be considered as a `compound function name' which names itself,
> plus it gives compilers an easy opportunity for a simple open-coding
> optimization. It won't cause a conflict, because implementation-defined
> compound function names would not use the symbol CL:LAMBDA.
Lambda expressions are often called anonymous functions, but we
could also call them function literals. Then we'd say that the car
of a form which is a function call must be either a function name (a
symbol) or a function literal (a lambda expression). The standard
only allows symbols as function names in function calls (though it
is less restrictive in other contexts, e.g. (DEFUN (SETF FOO) ...)).
I suppose another reason why function calls are more restricted is
for robustness, i.e. to catch malformed instances early.
A form whose car is LAMBDA was invalid before the LAMBDA macro was
introduced (I believe to allow a more Schemish style of programming
in Common Lisp---it is a contentious issue whether that was a good
idea).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov <········@poboxes.com> writes:
> A form whose car is LAMBDA was invalid before the LAMBDA macro was
> introduced (I believe to allow a more Schemish style of
> programming in Common Lisp---it is a contentious issue whether
> that was a good idea).
No, that's backwards. The LAMBDA macro has nothing to do with whether
you can use a LAMBDA in the CAR position since the macro is only used
when a LAMBDA expression occurs in a value position (i.e. not the
CAR).
Also the LAMBDA macro was introduced--according to Kent Pitman--in
order to make it possible to write an ISLISP compatibility library in
ANSI standard Common Lisp.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>
>> A form whose car is LAMBDA was invalid before the LAMBDA macro was
^^^^^^^^^^^^^^^^^^^^^^^^^^
>> introduced (I believe to allow a more Schemish style of
>> programming in Common Lisp---it is a contentious issue whether
>> that was a good idea).
>
> No, that's backwards. The LAMBDA macro has nothing to do with whether
> you can use a LAMBDA in the CAR position since the macro is only used
> when a LAMBDA expression occurs in a value position (i.e. not the
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
> CAR).
Well, "a lambda expression in a value position" is the same as "a
form whose car is LAMBDA" (the symbol LAMBDA).
> Also the LAMBDA macro was introduced--according to Kent Pitman--in
> order to make it possible to write an ISLISP compatibility library in
> ANSI standard Common Lisp.
I'd forgotten about ISLISP compatibility, and must have picked up an
urban myth instead (unless that was the reason why ISLISP had that
construct, but I speculate), thanks for the correction.
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov <········@poboxes.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Vassil Nikolov <········@poboxes.com> writes:
> >
> >> A form whose car is LAMBDA was invalid before the LAMBDA macro was
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> introduced (I believe to allow a more Schemish style of
> >> programming in Common Lisp---it is a contentious issue whether
> >> that was a good idea).
> >
> > No, that's backwards. The LAMBDA macro has nothing to do with whether
> > you can use a LAMBDA in the CAR position since the macro is only used
> > when a LAMBDA expression occurs in a value position (i.e. not the
> ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
> > CAR).
>
>
> Well, "a lambda expression in a value position" is the same as "a
> form whose car is LAMBDA" (the symbol LAMBDA).
((lambda (x) x) 1)
^^^^^^^^^^^^^^
It seems to me that this a "form whose car is LAMBDA" but not a "lambda
expression in a value position".
Cheers,
mwh
--
That one is easily explained away as massively intricate
conspiracy, though. -- Chris Klein, alt.sysadmin.recovery
From: Coby Beck
Subject: Re: spec 3.1.2.1.2 and the lambda exception
Date:
Message-ID: <4mJWc.2503$A8.1664@edtnps89>
"Michael Hudson" <···@python.net> wrote in message
···················@pc150.maths.bris.ac.uk...
> Vassil Nikolov <········@poboxes.com> writes:
> > Peter Seibel <·····@javamonkey.com> writes:
> > > Vassil Nikolov <········@poboxes.com> writes:
> > >> A form whose car is LAMBDA was invalid before the LAMBDA macro was
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >> introduced (I believe to allow a more Schemish style of
> > >> programming in Common Lisp---it is a contentious issue whether
> > >> that was a good idea).
> > >
> > > No, that's backwards. The LAMBDA macro has nothing to do with whether
> > > you can use a LAMBDA in the CAR position since the macro is only used
> > > when a LAMBDA expression occurs in a value position (i.e. not the
> > ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
> > > CAR).
> >
> > Well, "a lambda expression in a value position" is the same as "a
> > form whose car is LAMBDA" (the symbol LAMBDA).
>
> ((lambda (x) x) 1)
> ^^^^^^^^^^^^^^
> It seems to me that this a "form whose car is LAMBDA" but not a "lambda
> expression in a value position".
A form with LAMBDA in the CAR position:
=>(lambda (x) x)
aka a LAMBDA expression.
A form with a LAMBDA expression in a value position:
=>(mapcar (lambda (x) x) (list y))
A form with a LAMBDA expression in the CAR position:
=>((lambda (x) x) y)
aka a form with a form with a LAMBDA in the CAR position in the CAR
position.
A form with LAMBDA in a value position:
(foo 3 lambda)
No?
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> A form with LAMBDA in the CAR position:
> =>(lambda (x) x)
> aka a LAMBDA expression.
I believe a form (in a value position) with LAMBDA in the CAR position
is just a macro call, not a real lambda expression. However, the
macro will expand to a special form with a lambda expression inside.
> A form with a LAMBDA expression in the CAR position:
> =>((lambda (x) x) y)
Yes, and the entire form is a lambda form.
From CLHS:
lambda expression n. a list which can be used in place of a function
name in certain contexts to denote a function by directly describing
its behavior rather than indirectly by referring to the name of an
established function; its name derives from the fact that its first
element is the symbol lambda. See lambda.
lambda form n. a form that is a list and that has a first element
which is a lambda expression representing a function to be called on
arguments which are the result of evaluating subsequent elements of
the lambda form.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff <·········@nocrew.org> writes:
> [...]
> I believe a form (in a value position) with LAMBDA in the CAR position
> is just a macro call, not a real lambda expression. However, the
> macro will expand to a special form with a lambda expression inside.
> [...]
>
> lambda expression n. a list which can be used in place of a function
> name in certain contexts [...]
I believe we can consider a call to the LAMBDA macro to be in one of
those contexts---or is there a reason why we shouldn't?
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov <········@poboxes.com> writes:
> Lars Brinkhoff <·········@nocrew.org> writes:
> > I believe a form (in a value position) with LAMBDA in the CAR position
> > is just a macro call, not a real lambda expression.
> > [...]
> > lambda expression n. a list which can be used in place of a function
> > name in certain contexts [...]
>
> I believe we can consider a call to the LAMBDA macro to be in one of
> those contexts---or is there a reason why we shouldn't?
In my opinion, you can't use a call to the lambda macro in place of a
function name, because in a context where you can use a macro, a
symbol will name a variable.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff <·········@nocrew.org> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>> Lars Brinkhoff <·········@nocrew.org> writes:
>> > I believe a form (in a value position) with LAMBDA in the CAR position
>> > is just a macro call, not a real lambda expression.
>> > [...]
>> > lambda expression n. a list which can be used in place of a function
>> > name in certain contexts [...]
>>
>> I believe we can consider a call to the LAMBDA macro to be in one of
>> those contexts---or is there a reason why we shouldn't?
>
> In my opinion, you can't use a call to the lambda macro in place of a
> function name, because in a context where you can use a macro, a
> symbol will name a variable.
Hmmmmmm...
Here are five examples, in each of which a list whose car is LAMBDA
appears:
(#1=(lambda (x) x) 1)
(funcall (function #2=(lambda (x) x)) 1)
(funcall #3=(lambda (x) x) 1)
(coerce (quote #4=(lambda (x) x)) 'function)
(compile nil (quote #5=(lambda (x) x)))
Is only #3# not a lambda expression?
Note: (funcall (quote (lambda (x) x)) 1) used to be legal, but no
longer is.
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Lars Brinkhoff <·········@nocrew.org> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>> Here are five examples, in each of which a list whose car is LAMBDA
>> appears:
>>
>> (#1=(lambda (x) x) 1)
>>
>> (funcall (function #2=(lambda (x) x)) 1)
>>
>> (funcall #3=(lambda (x) x) 1)
>>
>> (coerce (quote #4=(lambda (x) x)) 'function)
>>
>> (compile nil (quote #5=(lambda (x) x)))
>>
>> Is only #3# not a lambda expression?
>
> Here are some more:
>
> (print (quote (lambda (x) y)))
>
> (defmacro foo (lambda (x) y) 42)
>
> (case foo (lambda (x) y))
>
> (let (lambda (x)) 42)
Yes... I should have been more precise and written something like,
"a list appears whose car is LAMBDA and whose immediate treatment is
as an anonymous function".
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Michael Hudson" <···@python.net> wrote in message
> ···················@pc150.maths.bris.ac.uk...
>> Vassil Nikolov <········@poboxes.com> writes:
>> > Peter Seibel <·····@javamonkey.com> writes:
>> > > Vassil Nikolov <········@poboxes.com> writes:
>> > >> A form whose car is LAMBDA was invalid before the LAMBDA macro was
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > >> introduced (I believe to allow a more Schemish style of
>> > >> programming in Common Lisp---it is a contentious issue whether
>> > >> that was a good idea).
>> > >
>> > > No, that's backwards. The LAMBDA macro has nothing to do with whether
>> > > you can use a LAMBDA in the CAR position since the macro is only used
>> > > when a LAMBDA expression occurs in a value position (i.e. not the
>> > ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>> > > CAR).
>> >
>> > Well, "a lambda expression in a value position" is the same as "a
>> > form whose car is LAMBDA" (the symbol LAMBDA).
>>
>> ((lambda (x) x) 1)
>> ^^^^^^^^^^^^^^
>> It seems to me that this a "form whose car is LAMBDA" but not a "lambda
>> expression in a value position".
>
> A form with LAMBDA in the CAR position:
> =>(lambda (x) x)
> aka a LAMBDA expression.
Not quite: a lambda expression is not a "form with LAMBDA in the CAR
position", it is a "_list_ with LAMBDA in the CAR position".
> A form with a LAMBDA expression in a value position:
> =>(mapcar (lambda (x) x) (list y))
Yes.
> A form with a LAMBDA expression in the CAR position:
> =>((lambda (x) x) y)
> aka a form with a form with a LAMBDA in the CAR position in the CAR
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> position.
"... a form with a _list_ with a LAMBDA in the CAR position in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
CAR position."
The car of a Common Lisp form isn't a form.
> A form with LAMBDA in a value position:
> (foo 3 lambda)
Yes.
> No?
Not quite, yes, not quite, yes.
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Michael Hudson <···@python.net> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>
>> Peter Seibel <·····@javamonkey.com> writes:
>>
>> > Vassil Nikolov <········@poboxes.com> writes:
>> >
>> >> A form whose car is LAMBDA was invalid before the LAMBDA macro was
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> introduced (I believe to allow a more Schemish style of
>> >> programming in Common Lisp---it is a contentious issue whether
>> >> that was a good idea).
>> >
>> > No, that's backwards. The LAMBDA macro has nothing to do with whether
>> > you can use a LAMBDA in the CAR position since the macro is only used
>> > when a LAMBDA expression occurs in a value position (i.e. not the
>> ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>> > CAR).
>>
>>
>> Well, "a lambda expression in a value position" is the same as "a
>> form whose car is LAMBDA" (the symbol LAMBDA).
>
> ((lambda (x) x) 1)
> ^^^^^^^^^^^^^^
> It seems to me that this a "form whose car is LAMBDA" but not a "lambda
> expression in a value position".
By definition, a form is something in a for-evaluation position ("an
object to be evaluated"), so ``(lambda (x) x)'' above is not a form
(in Common Lisp; it is a lambda expression that is the car of a
lambda form).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov <········@poboxes.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>> Vassil Nikolov <········@poboxes.com> writes:
>>
>>> A form whose car is LAMBDA was invalid before the LAMBDA macro was
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> introduced (I believe to allow a more Schemish style of
>>> programming in Common Lisp---it is a contentious issue whether
>>> that was a good idea).
>>
>> No, that's backwards. The LAMBDA macro has nothing to do with whether
>> you can use a LAMBDA in the CAR position since the macro is only used
>> when a LAMBDA expression occurs in a value position (i.e. not the
> ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>> CAR).
>
>
> Well, "a lambda expression in a value position" is the same as "a
> form whose car is LAMBDA" (the symbol LAMBDA).
Ah, I misread your original message. Apologies. I read "form whose car
is LAMBDA" as "form whose car is a LAMBDA expression" which is
obviously totally different. Sorry.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Ross Lippert <·······@MATHSTATION031.MIT.EDU> wrote in message news:<···············@MATHSTATION031.MIT.EDU>...
> However, I can do
> ((lambda (y) (+ 1 y)) 1)
> without having to use funcall, though doing
> (funcall (lambda (y) (+ 1 y)) 1)
> works too.
I don't know whether this will help, but one way to look at this is
not that an exception is made for allowing a lambda expression to
serve in place of a function name in the first position of an
expression, but rather that a LAMBDA macro exists as a convenience so
that you don't have to use the FUNCTION operator or its #' shorthand
when you need an a funtion object elsewhere in an expression.
The reason you can write
(funcall (lambda ...))
at all is that there exists a LAMBDA macro which rewrites (LAMBDA ...)
into (FUNCTION (LAMBDA ...)). In other words, it translates a lambda
expression into a call of the appropriate operator that actually
generates the closure from a lambda expression. Funcall needs a
closure or a symbol.
Without the macro, you would have to write:
(funcall #'(lambda ...))
This is the special case. Other function names have to be treated
explicitly:
(funcall #'y x) ;; NOT (funcall y x)
> The reason seems to come down to a place in the CL spec called
> 3.1.2.1.2 which says that the car of the s-exp to be interpreted must
> be a special form, a macro, a symbol or a lambda expression.
> http://www.lispworks.com/reference/HyperSpec/Body/03_abab.htm
Lambdas in the first position of a list are deeply traditional. Before
the LET operator was invented, that is how you wrote a block of code
with local variables. Superficially,
(LET ((X A) (Y B)) ...)
is equivalent ot
((LAMBDA (X Y) ...) A B)
but it's more convenient because it juxtaposes the variables with the
expressions that provide their initial values.
> I guess that 3.1.2.1.2 allows lambdas and no other expressions
> because either:
> 1) there is some good reason to allow lambda expressions in the car.
> 2) there is some good reason to disallow arbitrary function-returning
> expressions in the car.
There is a good reason for 2, because then (FOO) is ambiguous. Do we
use the function binding of FOO to produce the function? Or do we
follow the value binding?
···@ashi.footprints.net (Kaz Kylheku) writes:
> Ross Lippert <·······@MATHSTATION031.MIT.EDU> wrote in message news:<···············@MATHSTATION031.MIT.EDU>...
> > However, I can do
> > ((lambda (y) (+ 1 y)) 1)
> > without having to use funcall, though doing
> > (funcall (lambda (y) (+ 1 y)) 1)
> > works too.
>
> I don't know whether this will help, but one way to look at this is
> not that an exception is made for allowing a lambda expression to
> serve in place of a function name in the first position of an
> expression, but rather that a LAMBDA macro exists as a convenience so
> that you don't have to use the FUNCTION operator or its #' shorthand
> when you need an a funtion object elsewhere in an expression.
Well, in that case, since the first item in the call list is not
evaluated, the macro LAMBDA is not invoked. EVAL interprets directy
the list (lambda (...) ...) as a function, and ((lambda (...) ...) ...)
as a function call.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
In article <···············@MATHSTATION031.MIT.EDU>,
Ross Lippert <·······@MATHSTATION031.MIT.EDU> wrote:
> I have been trying to learn some lisp. I have had some experience in
> scheme, which is probably why I even got disturbed by that which is
> the source of my question.
>
> Playing around with the age old bank-account example I did something
> equivalent to
> (defun make-adder (x) (lambda (y) (+ x y)))
> ((make-adder 1) 1)
> and of course, I got an error. What I mean to do here is done by
> using funcall. This is part of that 1-namespace vs 2-namespace
> issue, which divides scheme and lisp, I know.
>
> However, I can do
> ((lambda (y) (+ 1 y)) 1)
> without having to use funcall, though doing
> (funcall (lambda (y) (+ 1 y)) 1)
> works too.
>
> The reason seems to come down to a place in the CL spec called
> 3.1.2.1.2 which says that the car of the s-exp to be interpreted must
> be a special form, a macro, a symbol or a lambda expression.
> http://www.lispworks.com/reference/HyperSpec/Body/03_abab.htm
>
> When evaluated, these two things look nearly the same:
> [2]> (lambda (y) (+ 1 y))
> #<CLOSURE :LAMBDA (Y) (+ 1 Y)>
> [3]> (make-adder 1)
> #<CLOSURE :LAMBDA (Y) (+ X Y)>
> Yet, upon substitution into an s-exp, they can do different things.
> Of course, this tells me that evaluation in the car position is not
> the same as evaluation of the arguments, which is to be expected
> from the wording of 3.1.2.1.2. Still it is disconcerting.
>
> I guess that 3.1.2.1.2 allows lambdas and no other expressions
> because either:
> 1) there is some good reason to allow lambda expressions in the car.
> 2) there is some good reason to disallow arbitrary function-returning
> expressions in the car.
>
> Which is it and why?
>
> I read some of the past articles on this group about 3.1.2.1.2 and
> did not see this issue discussed.
>
> Thank you,
>
> -r
The first place in a list is not evaluated normally. So
((foo)) does not work. It allows lambda forms there, because
they are kind of constant objects in that place, known at
compile time.
Imagine this (not CL code):
(let ((foo #'sin))
(flet ((return-cos () #'cos))
(list (foo)
((return-cos)))))
(foo) would do what? It would still go to the function FOO
defined somewhere else.
((return-cos)) would do what? It would invoke the value of RETURN-COS?
That would make things even more confused. ;-)
Ross Lippert <·······@MATHSTATION031.MIT.EDU> writes:
> I have been trying to learn some lisp. I have had some experience in
> scheme, which is probably why I even got disturbed by that which is
> the source of my question.
>
> Playing around with the age old bank-account example I did something
> equivalent to
> (defun make-adder (x) (lambda (y) (+ x y)))
> ((make-adder 1) 1)
> and of course, I got an error. What I mean to do here is done by
> using funcall. This is part of that 1-namespace vs 2-namespace
> issue, which divides scheme and lisp, I know.
> [...]
> I guess that 3.1.2.1.2 allows lambdas and no other expressions
> because either:
> 1) there is some good reason to allow lambda expressions in the car.
> 2) there is some good reason to disallow arbitrary function-returning
> expressions in the car.
>
> Which is it and why?
Both.
1: Because a list of the form (lambda (arg...) exp...) IS a function.
I mean, this is a function:
+-----------------------------------------------+
| |
| +---+---+ +---+---+ +---+---+ +---+---+ |
| | * | * |-->| * | * |-->| * | * |-->| * |NIL| |
| +---+---+ +---+---+ +---+---+ +---+---+ |
| | | | | |
| v | v v |
| +--------+ | +------+ +------+ |
| | LAMBDA | | | EXP0 | | EXP1 | |
| +--------+ | +------+ +------+ |
| v |
| +---+---+ +---+---+ |
| | * | * |-->| * |NIL| |
| +---+---+ +---+---+ |
| | | |
| v v |
| +------+ +------+ |
| | ARG0 | | ARG1 | |
| +------+ +------+ |
| |
+-----------------------------------------------+
2: Because there is no difference between a function call and a
variable evaluatoin. Both are executed with EVAL, and since
Common-Lisp is a lisp-2, it won't evaluate the first item in a
sexp.
Note however that you can still play some tricks:
CL-USER> (defun make-adder (x) `(lambda (y) (+ ,x y)))
MAKE-ADDER
CL-USER> (#.(make-adder 1) 1)
2
Of course, the adder will be created at read time instead of run time.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On Tue, 24 Aug 2004 00:31:51 +0200, Pascal Bourguignon wrote:
> Note however that you can still play some tricks:
>
> CL-USER> (defun make-adder (x) `(lambda (y) (+ ,x y)))
> MAKE-ADDER
> CL-USER> (#.(make-adder 1) 1)
> 2
>
> Of course, the adder will be created at read time instead of run time.
Its source will be created at read time, but the actual function object
will be created at runtime. If you want to use a closure created at read
time, it must be applied using something like funcall.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <···············@MATHSTATION031.MIT.EDU>,
Ross Lippert <·······@MATHSTATION031.MIT.EDU> wrote:
> I guess that 3.1.2.1.2 allows lambdas and no other expressions
> because either:
> 1) there is some good reason to allow lambda expressions in the car.
> 2) there is some good reason to disallow arbitrary function-returning
> expressions in the car.
>
> Which is it and why?
It's a historical thing. Before LET was added to the Lisp language,
LAMBDA was the mechanism used to establish local variable bindings (yes,
I know PROG also created variable bindings, but I think it also may have
come a little later). The equivalent of:
(let ((var1 val1)
(var2 val2))
body...)
was:
((lambda (var1 var2) body...) val1 val2)
The reason for disallowing arbitrary expressions in the function
position is that it results in an ambiguity:
(setq foo #'+)
(setf (symbol-function 'foo) #'-)
(foo 1 2)
If you expect the car to be evaluated normally, it should use FOO's
variable binding. But Common Lisp uses different evaluation rules when
a place in the form is expected to denote a function rather than
arbitrary data.
Maclisp actually had an option that you could set to enable evaluation
of the car of a form. I don't remember anyone using it seriously.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***