What exactly is the difference between the two? The CLtL2 says that
a lambda-expression is a list with some certain syntax. Ok so far.
However, CLtL2 doesn't say what a lambda-expression evaluates to.
Under CLISP, it seems to evaluate to the function that it defines.
If that is the case, why use #' before lambda-expressions? What will
break if I don't use it?
Is it the only difference that one is a list and the other is a function?
Something like a digit `3' and a number (value) 3?
--
,oOo.Bc -=EE Krzysztof Parzyszek <······@iname.com> 4/12/2001 5:15pm
-'7' `L' ---This sentence has exactly threee erors.
······@iname.com (Krzysztof Parzyszek) writes:
>
> What exactly is the difference between the two? The CLtL2 says that
Btw, CLTL2 is not the language definition.
Check out the Common Lisp HyperSpec (CLHS).
http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/
> a lambda-expression is a list with some certain syntax.
A lambda expression is an expression that is either a kind of kind of
form or a specially allowed element as the car of another form, called
a lambda form.
> Ok so far.
> However, CLtL2 doesn't say what a lambda-expression evaluates to.
LAMBDA is a macro. LAMBDA expressions used as forms, that is, forms
that look like (lambda ...) expand into FUNCTION expressions,
(function (lambda ...)) and evaluate to objects of type function.
A lexical closure is an abstract term that is sometimes used to describe
a kind of function which contains free references to the lexical environment
in which it was created.
> Under CLISP, it seems to evaluate to the function that it defines.
Yes.
> If that is the case, why use #' before lambda-expressions? What will
> break if I don't use it?
It used to be required to use it. Some people like to put it there to
specially notate that it's a function. Others hate the notation so don't
like to see it. The version without the #' is provided for minimal
notational compatibility with other dialects/languages that don't use
that notation, such as Scheme.
> Is it the only difference that one is a list and the other is a function?
> Something like a digit `3' and a number (value) 3?
There are dialects of Lisp (Brian Smith's 3lisp comes to mind) where
there are special datatypes called numerals that evaluate to numbers so
that numbers don't self-evaluate. In such dialects, you have to write
the quoted numeral '37 and it evalutes to the number 37. I guess by
analogy you could say a lambda expression is the source representation,
but it is more complex than a numeral in the sense that if you do
(lambda (x) x) you are talking about a function taht can move anywhere
and is not affected by its environment but (lambda (x) (+ x y)) is
affected by its lexical environment. In this latter case, the result is
not merely a function but a closure; the closure remembers the lexical
environment in which the object is created.
The representation does NOT work this way, but CONCEPTUALLY a lexical
closure is a cons whose "car" is special function that takes a hidden
argument of the environment, and whose "cdr" is the lexical
environment to be passed to the special function. That way, if you
repeatedly exeucte the lambda expression creating new closures, you
get the same (eq) car but only a different cdr (lexical env).
On Wed, 15 Aug 2001 02:22:32 GMT, Kent M Pitman wrote:
>
> A lexical closure is an abstract term that is sometimes used to describe
> a kind of function which contains free references to the lexical environment
> in which it was created.
First, thank you all who replied.
I understand what a lexical closure is. I know Scheme and now I'm trying to
move on to Common Lisp. In Scheme ``(lambda ...)'' evaluates to a lexical
closure, but apparently it's not as simple in CL.
Correct me, if the below is wrong:
((lambda (x) (* x x)) 2) ==> 4 ;; here `lambda' makes a lambda-form
(funcall (lambda (x) (* x x)) 2) ==> 4 ;; `lambda' is now a macro that
;; expands to (function (lambda ...))
Forgive me if it's trivial, but it seems to me like the car of a form
to be evaluated, unlike Scheme, is supposed to be a function name
(or a lambda-expression), and cannot be just an expression that evaluates
to a lexical closure. So, the distinction between functions (understood
here as symbols denoting a function or lambda-expressions) and lexical
closures is more explicit in Common Lisp. Is that right?
>> If that is the case, why use #' before lambda-expressions? What will
>> break if I don't use it?
>
> It used to be required to use it. Some people like to put it there to
> specially notate that it's a function. Others hate the notation so don't
> like to see it. The version without the #' is provided for minimal
> notational compatibility with other dialects/languages that don't use
> that notation, such as Scheme.
So, wherever the #' could be placed before a ``(lambda ...)'', the
word ``lambda'' denotes a macro that is going to add that #' anyway..?
--
,oOo.Bc -=EE Krzysztof Parzyszek <······@iname.com> 4/12/2001 5:15pm
-'7' `L' ---This sentence has exactly threee erors.
In article <·····················@cl3069461-a.rchstr1.mn.home.com>,
Krzysztof Parzyszek wrote:
>I understand what a lexical closure is. I know Scheme and now I'm trying to
>move on to Common Lisp. In Scheme ``(lambda ...)'' evaluates to a lexical
>closure, but apparently it's not as simple in CL.
>
>Correct me, if the below is wrong:
>
>((lambda (x) (* x x)) 2) ==> 4 ;; here `lambda' makes a lambda-form
Yes; here it is just a lambda list that appears in the same context
where you might use a function name.
>(funcall (lambda (x) (* x x)) 2) ==> 4 ;; `lambda' is now a macro that
> ;; expands to (function (lambda ...))
Yes.
>Forgive me if it's trivial, but it seems to me like the car of a form
>to be evaluated, unlike Scheme, is supposed to be a function name
In Lisp, the first position of an evaluated form is treated specially.
There are lots of differences between Lisp and Scheme. For example,
in Lisp, a symbol has an independent binding to a function or value.
In Scheme, a symbol has one binding.
In Lisp, you bind a symbol to a function as a value, like say this:
(setq x (lambda (...) ...))
you cannot call it like this:
(x ...)
When you evaluate the above, x is expected to have a function binding,
set up by defun, flet or labels. To call ``through'' x, you can use
apply or funcall:
(funcall x ...)
Here, x is in the second position of the form, so it is treated
differently. Its value binding is resolved to the closure, which is a
suitable argument to funcall.
>So, wherever the #' could be placed before a ``(lambda ...)'', the
>word ``lambda'' denotes a macro that is going to add that #' anyway..?
That's it.
······@iname.com (Krzysztof Parzyszek) writes:
>
> On Wed, 15 Aug 2001 02:22:32 GMT, Kent M Pitman wrote:
> >
> > A lexical closure is an abstract term that is sometimes used to describe
> > a kind of function which contains free references to the lexical environment
> > in which it was created.
>
> First, thank you all who replied.
>
>
> I understand what a lexical closure is. I know Scheme and now I'm trying to
> move on to Common Lisp. In Scheme ``(lambda ...)'' evaluates to a lexical
> closure, but apparently it's not as simple in CL.
>
> Correct me, if the below is wrong:
>
> ((lambda (x) (* x x)) 2) ==> 4 ;; here `lambda' makes a lambda-form
>
> (funcall (lambda (x) (* x x)) 2) ==> 4 ;; `lambda' is now a macro that
> ;; expands to (function (lambda ...))
>
>
> Forgive me if it's trivial, but it seems to me like the car of a form
> to be evaluated, unlike Scheme, is supposed to be a function name
> (or a lambda-expression), and cannot be just an expression that evaluates
> to a lexical closure. So, the distinction between functions (understood
> here as symbols denoting a function or lambda-expressions) and lexical
> closures is more explicit in Common Lisp. Is that right?
In Scheme, in (f a1 a2 a3), every position f, a1, a2, a3 is evaluated
equivalently (and in no particular order, btw). In CL, f must be a symbol
(whose value is fetched from the function namespace) or a lambda expression
(which describes a function in the current lexical environment). A lambda
expression is the only non-atomic car of form permitted and is allowed by
special case. If a lambda expression happens elsewhere, it's just a normal
form and that's why we made it be a macro to turn itself into #'(lambda...).
>
> >> If that is the case, why use #' before lambda-expressions? What will
> >> break if I don't use it?
> >
> > It used to be required to use it. Some people like to put it there to
> > specially notate that it's a function. Others hate the notation so don't
> > like to see it. The version without the #' is provided for minimal
> > notational compatibility with other dialects/languages that don't use
> > that notation, such as Scheme.
>
> So, wherever the #' could be placed before a ``(lambda ...)'', the
> word ``lambda'' denotes a macro that is going to add that #' anyway..?
No, just the opposite. If you put #' there, you are saying to treat the
lambda expression in the same magic way that the car of a form is treated.
If you omit the #', you just have an ordinary expression. It used to be
that you'd get "LAMBDA undefined function" or worse, it would try to evaluate
the arguments and you'd get something like "X undefined function" in
(lambda (x) ...). We "fixed" this by making LAMBDA be a macro that turns
the form (lambda (x) x) into (function (lambda (x) x)). FUNCTION is a special
form and its argument is treated magically. It's kind of a roundabout way
to give brain compatibility with Scheme's more primitive LAMBDA.
In article <···············@world.std.com>, Kent M Pitman wrote:
>······@iname.com (Krzysztof Parzyszek) writes:
>> So, wherever the #' could be placed before a ``(lambda ...)'', the
>> word ``lambda'' denotes a macro that is going to add that #' anyway..?
>
>No, just the opposite.
That's what I thought too at first. But Krzysztof's sentence above conveys
a correct understanding using clever wording that is reasonably accurate,
though easy to misread.
After a few passes, I read it as: in an (evaluation) context where a #'
could (legally) appear before a lambda, if it does not appear, that
lambda is treated as the lambda macro.
That seems approximately right.
···@ashi.footprints.net (Kaz Kylheku) writes:
>
> In article <···············@world.std.com>, Kent M Pitman wrote:
> >······@iname.com (Krzysztof Parzyszek) writes:
> >> So, wherever the #' could be placed before a ``(lambda ...)'', the
> >> word ``lambda'' denotes a macro that is going to add that #' anyway..?
> >
> >No, just the opposite.
>
> That's what I thought too at first. But Krzysztof's sentence above conveys
> a correct understanding using clever wording that is reasonably accurate,
> though easy to misread.
>
> After a few passes, I read it as: in an (evaluation) context where a #'
> could (legally) appear before a lambda, if it does not appear, that
> lambda is treated as the lambda macro.
>
> That seems approximately right.
Ah. Right. Thanks.
Kent M Pitman <······@world.std.com> writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
[snip]
> > After a few passes, I read it as: in an (evaluation) context where a #'
> > could (legally) appear before a lambda, if it does not appear, that
> > lambda is treated as the lambda macro.
> >
> > That seems approximately right.
>
> Ah. Right. Thanks.
Kent,
I have vague recollection of an off hand remark from someone related
to the ANSI committee (I don't mean to imply that it was you) that one
of the reasons for making (lambda () ) expand into #'(lambda ()) was
the fact that a user could not portably define such a lambda macro
themselves. Given that some people wanted to have the ability to
leave out the #' and that it would not be hard for the vendors to
implement the lambda macro it was stuck in the standard. I looked at
the issues in the HS but didn't find anything that looked related.
I haven't had my morning coffee yet so I just may be delusional, but
do you remember some such rational for doing this.
-Eric
>>>>> "Eric" == Eric Dahlman <····@lossage.org> writes:
Eric> Kent,
Eric> I have vague recollection of an off hand remark from someone related
Eric> to the ANSI committee (I don't mean to imply that it was you) that one
Eric> of the reasons for making (lambda () ) expand into #'(lambda ()) was
Eric> the fact that a user could not portably define such a lambda macro
Eric> themselves. Given that some people wanted to have the ability to
Eric> leave out the #' and that it would not be hard for the vendors to
Eric> implement the lambda macro it was stuck in the standard. I looked at
Eric> the issues in the HS but didn't find anything that looked related.
Can you say why it would have been hard to implement the lambda macro?
In CMUCL, lambda is:
(defmacro lambda (&whole form &rest bvl-decls-and-body)
(declare (ignore bvl-decls-and-body))
`#',form)
Why wouldn't this work for everyone?
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> Can you say why it would have been hard to implement the lambda macro?
Heh. Sure. Because both implementations and users are forbidden from adding
definitions to things in the CL package.
> In CMUCL, lambda is:
>
> (defmacro lambda (&whole form &rest bvl-decls-and-body)
> (declare (ignore bvl-decls-and-body))
> `#',form)
>
> Why wouldn't this work for everyone?
(a) Because it's not conforming.
(b) Because you'd get redefinition warnings ... from others who
were HOPEFULLY trying to do the same thing. Or worse, the
other definition you clobbered (or that clobbered you) might
be written by an APL programmer or a VLSI designer or a linguist
or a font designer or a political activist with a different but
well-meaning theory of what a funciton named LAMBDA should do.
Eric Dahlman <····@lossage.org> writes:
> Kent,
>
> I have vague recollection of an off hand remark from someone related
> to the ANSI committee (I don't mean to imply that it was you) that one
> of the reasons for making (lambda () ) expand into #'(lambda ()) was
> the fact that a user could not portably define such a lambda macro
> themselves.
I think it was me who made that remark. I thought there was a cleanup
issue on this, and that the remark is in the issue. I guess it's badly
indexed, since LAMBDA doesn't seem to cite any associated issues. Darn
that Project Editor for not keeping better records.. I'll hunt around
for a better reference.
Kent M Pitman <······@world.std.com> writes:
> Eric Dahlman <····@lossage.org> writes:
>
> > Kent,
> >
> > I have vague recollection of an off hand remark from someone related
> > to the ANSI committee (I don't mean to imply that it was you) that one
> > of the reasons for making (lambda () ) expand into #'(lambda ()) was
> > the fact that a user could not portably define such a lambda macro
> > themselves.
>
> I think it was me who made that remark. I thought there was a cleanup
> issue on this, and that the remark is in the issue. I guess it's badly
> indexed, since LAMBDA doesn't seem to cite any associated issues. Darn
> that Project Editor for not keeping better records.. I'll hunt around
> for a better reference.
I know, you just can't find good help these days. ;-)
While we are picking on that poor scribe. I hold him personally
responsible for the atrophying of a large portion of my brain. When all
those nitpicky details about the language are only a C-M-h[1] away I
promptly quit worrying about them and they just slipped away. Now my
work is more efficient but it has significantly reduced my status as a
geek at cocktail parties. The sheer ease of reference has prevented
me from acquiring the knowledge of a mass of minutiae necessary as
ammunition when sparring for the alpha geek position. When challenged
"How would you solve this problem?" the response "I'd press C-M-h and
be taken to the relevant part of the spec where I would just READ the
answer." has never been a good retort. There is no suffering, no
challenge, nothing to commiserate about. Damn you Kent!
Because of Common Lisp and the HyperSpec I am forced to concern myself
with actual domain problems and deeper semantic issues, nobody gets
points for this stuff. I am all for adding templates, automatically
generated "copy constructors", object serialization and a syntax which
is ultimately more socially beneficial like XML's! If I am not
suffering at least as much as my peers I will not earn their respect!
Kent, once I figure out how to calculate the monetary cost of my lost
geek status because of you and your efforts... you will be hearing
from my language lawyer!
-Eric ··@R for all IO would be a good start" Dahlman
Footnotes:
[1] The individual binding experience my vary, please consult C-h-a
"hyperspec" for the functions and bindings available in your
area.[2]
[2] Recursive caveat.
On Thu, 16 Aug 2001 06:06:28 GMT, Kaz Kylheku wrote:
> In article <···············@world.std.com>, Kent M Pitman wrote:
>>······@iname.com (Krzysztof Parzyszek) writes:
>>> So, wherever the #' could be placed before a ``(lambda ...)'', the
>>> word ``lambda'' denotes a macro that is going to add that #' anyway..?
>>
>>No, just the opposite.
>
[...]
> After a few passes, I read it as: in an (evaluation) context where a #'
> could (legally) appear before a lambda, if it does not appear, that
> lambda is treated as the lambda macro.
>
> That seems approximately right.
That's exactly what I meant. Sometimes I forget that not everyone can
read my thoughts... :)
Thank you for clarification.
--
,oOo.Bc -=EE Krzysztof Parzyszek <······@iname.com> 4/12/2001 5:15pm
-'7' `L' ---This sentence has exactly threee erors.
In article <·····················@cl3069461-a.rchstr1.mn.home.com>,
Krzysztof Parzyszek wrote:
>What exactly is the difference between the two? The CLtL2 says that
>a lambda-expression is a list with some certain syntax. Ok so far.
>However, CLtL2 doesn't say what a lambda-expression evaluates to.
The Hyperspec clears up what a lambda-expression is. It says that ``[a]
lambda expression is a list that 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 funtion.''
So for instance you can write a lambda expression in the first position
of a form instead of a function name, and that expression will be
evaluated with the remainder of the form supplying the arguments:
((lambda (x) (* x x)) 3)
---> 9
which is equivalent to
(funcall #'(lambda (x) (* x x)) 3)
---> 9
>Under CLISP, it seems to evaluate to the function that it defines.
>If that is the case, why use #' before lambda-expressions? What will
>break if I don't use it?
You see, there exists in Common Lisp a lambda *macro*. And that macro
implements a shorthand which automatically applies (function ...) to
generate the closure. This is a labor saving mechanism, so you don't
have to remember the #' in contexts where it's painfully obvious
that you want a closure. The Right Thing (TM) happens.
So when you use, for instance,
(lambda (x) (* x x))
you are invoking the lambda *macro* which produces the transformation:
(function (lambda (x) (* x x)))
The function operator prevents the macro from applying recursively.
Try it:
(macroexpand '(lambda (x) (* x x)))
Pretty darn sneaky, wouldn't you say?
······@iname.com (Krzysztof Parzyszek) writes:
> However, CLtL2 doesn't say what a lambda-expression evaluates to.
> Under CLISP, it seems to evaluate to the function that it defines.
LAMBDA is a macro that provides the #' automatically. See CLHS.
So if you do
(defvar *func* (lambda () nil))
then Lisp macroexpands the lambda expression, resulting in
(defvar *func* #'(lambda () nil))
and when this is finally compiled and evaluated, Lisp parses the
lambda expression in the FUNCTION special form and you get the
function.
> If that is the case, why use #' before lambda-expressions?
Clarity, I guess.
> What will break if I don't use it?
Nothing, at least if the expression is at a position where it
will be evaluated.
> Is it the only difference that one is a list and the other is a function?
> Something like a digit `3' and a number (value) 3?
There are more levels here.
"(lambda () nil)"
is a string. The Lisp reader parses it to
(lambda () nil)
which is a list. When macroexpanded, it becomes
#'(lambda () nil)
which is another read syntax for
(function (lambda () nil))
which is still a list. When evaluated, it might become
#<Interpreted Function (LAMBDA () NIL) {4811B319}>
which is a function that can be called.