Hi everyone,
I still don't really understand. Hope somebody can help. What is the
different between:
1. (funcall #'(lambda (x) (char= #\a x)) #\a)
and
2. (funcall (lambda (x) (char= #\a x)) #\a)
are they the same?
Thanks.
Willie
In article <····························@posting.google.com>,
··········@yahoo.com (Willy) wrote:
> Hi everyone,
>
> I still don't really understand. Hope somebody can help. What is the
> different between:
>
> 1. (funcall #'(lambda (x) (char= #\a x)) #\a)
> and
>
> 2. (funcall (lambda (x) (char= #\a x)) #\a)
>
> are they the same?
(lambda ...) is a macro that expands into #'(lambda ...) - so they're
effectively the same. It really doesn't matter which one you use.
Pascal
··········@yahoo.com (Willy) writes:
> Hi everyone,
>
> I still don't really understand. Hope somebody can help. What is the
> different between:
>
> 1. (funcall #'(lambda (x) (char= #\a x)) #\a)
> and
>
> 2. (funcall (lambda (x) (char= #\a x)) #\a)
>
>
> are they the same?
Functionally, yes. LAMBDA is a funny creature. On the one hand it is a
special symbol whose presence as the CAR of a list indicates that list
is a "lambda expressions", essentially an anonymous function. (Or,
more accurately, an eponymous function since the name is the thing
itself.) Thus:
((lambda (x) (+ x 2)) 3) ==> 5
The lambda expression '(lambda (x) (+ x 2))' is both the name of the
function and the definition. For lambda expressions that occur in
places where a name of a function is expected (such as the first
element of a list as above) that's the whole story.
One place that expects the name of a function is the special operator
FUNCTION. (#', as you may know, is a reader macro FUNCTION). FUNCTION
takes as an argument the "name" of a function and returns the function
object. Well, since a lambda expression is just a funny looking
function name, passing a lambda expression to FUNCTION returns the
function object (i.e. the thing that can be FUNCALL'd, APPLY'd, or
passed as an argument to functions like MAPCAR) for that function.
(function (lambda (x) (+ x 2))) ==> #<Interpreted Function (unnamed) @ #x718de092>
is equivalent to:
#'(lambda (x) (+ x 2)) ==> #<Interpreted Function (unnamed) @ #x718d9c12>
On the other hand, LAMBDA is also a macro which expands into (FUNCTION
(LAMBDA ...)). In contexts where a list starting with LAMBDA is
evaluated, it is macro expanded into the same LAMBAD expression
wrapped in a FUNCTION call. The LAMBDA in the expansion isn't further
expanded because FUNCTION is a special operator whose argument is not
evaluated.
The point of all this is just a bit of syntactic sugar that some folks
find appealing (perhaps because it--in this one instance makes CL look
a bit more like Scheme or because they have a pile of code to be
ported from some pre-Common Lisp Lisp that had a similar feature) and
that others find silly.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Steven M. Haflich
Subject: Re: what diff #'(lambda...) to (lambda...)?
Date:
Message-ID: <3EF9096D.9040801@alum.mit.edu>
Peter Seibel wrote:
> Functionally, yes. LAMBDA is a funny creature. On the one hand it is a
> special symbol whose presence as the CAR of a list indicates that list
> is a "lambda expressions", essentially an anonymous function. (Or,
> more accurately, an eponymous function since the name is the thing
> itself.) Thus:
>
> ((lambda (x) (+ x 2)) 3) ==> 5
>
> The lambda expression '(lambda (x) (+ x 2))' is both the name of the
> function and the definition. For lambda expressions that occur in
> places where a name of a function is expected (such as the first
> element of a list as above) that's the whole story.
Peter, this naming sophistry is an interesting premise but it is
essentially incorrect.
A lambda expression denotes a function, but it does not always denote
the same function. Execution of (function (lambda ...)) returns a
function, but for a given identical #'(lambda ...) forms, the function
returned is not necessarily indistinguishable from the function returned
by other executions.
If a lambda expression is a null closure -- that is, it makes no free
references to surrounding lexical definitions -- then multiple occurrences
of that same lambda expression (same in the sense of equal, ignoring the
possibility of circular literal constants) are indistinguishable from each
other. But if "equal" lambda expressions make free references to lexical
constructs, the lexical environment is potentially a part of the function
object returned by execution of the fucntion special form, and therefore
the functions may be distinguishable.
Therefore a lambda expression is not the name of a function.
Here is a simple example:
(defun adder (n)
(lambda (x) (+ n x))
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Peter Seibel wrote:
>
> > Functionally, yes. LAMBDA is a funny creature. On the one hand it is a
> > special symbol whose presence as the CAR of a list indicates that list
> > is a "lambda expressions", essentially an anonymous function. (Or,
> > more accurately, an eponymous function since the name is the thing
> > itself.) Thus:
> > ((lambda (x) (+ x 2)) 3) ==> 5
>
> > The lambda expression '(lambda (x) (+ x 2))' is both the name of the
>
> > function and the definition. For lambda expressions that occur in
> > places where a name of a function is expected (such as the first
> > element of a list as above) that's the whole story.
>
> Peter, this naming sophistry is an interesting premise but it is
> essentially incorrect.
>
> A lambda expression denotes a function, but it does not always denote
> the same function. Execution of (function (lambda ...)) returns a
> function, but for a given identical #'(lambda ...) forms, the function
> returned is not necessarily indistinguishable from the function returned
> by other executions.
>
> If a lambda expression is a null closure -- that is, it makes no
> free references to surrounding lexical definitions -- then multiple
> occurrences of that same lambda expression (same in the sense of
> equal, ignoring the possibility of circular literal constants) are
> indistinguishable from each other. But if "equal" lambda expressions
> make free references to lexical constructs, the lexical environment
> is potentially a part of the function object returned by execution
> of the fucntion special form, and therefore the functions may be
> distinguishable.
>
> Therefore a lambda expression is not the name of a function.
>
> Here is a simple example:
>
> (defun adder (n)
> (lambda (x) (+ n x))
Fair enough--there certainly subtleties. But by the same argument is
the symbol FOO not the name of a function in the following
reimplementation of ADDER?
(defun adder (n)
(flet ((foo (x) (+ n x))) #'foo))
How about in this one?
(defun redifine-foo-adder (n)
(defun foo (x) (+ n x)))
I might be tempted to say rather that there is not necessarily a
one-to-one mapping between function names (whether nym or eponym) and
identity.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> How about in this one?
>
> (defun redifine-foo-adder (n)
> (defun foo (x) (+ n x)))
I think you meant
(defun rfa (n)
(defun rfa-aux (x) (+ n x))
#'rfa-aux)
I was going to do the same example, and I agree that the fact of the
naming per se is a red herring.
What is relevant is the time of execution.
(defun f (...) ...)
means approximately
(setf (symbol-function 'f) #'(lambda (...) (block f ...)))
so if you assume there are no intervening flets, so that (symbol-function 'f)
and #'f are equivalent, then
(defun f ...)
#'f
is the same as
#'(lambda ...)
But what is subtly different is that if the definition occurred at toplevel,
then it was evaluated (closed) at 'load time', while if it is in a
definition it is evaluated (closed) at 'execution time' of the function.
I sometimes call (lambda (x) x) an "anonymous function" and say that it is
its own name. This is why it is allowed in FUNCTION forms.
(function name)
can be (FUNCTION CAR) or (FUNCTION (LAMBDA (X) X)). Likewise it's why you
can say (CAR X) or ((LAMBDA (X) X) 3) because the car of a form is a
function name. HOWEVER, doing this glosses the fact that it's constantly
getting reconsidered in meaning. That is,
(let ((n 3))
(defun f (x) (+ x n)))
closes F at load time. So
(defun g (n)
(f n))
does not define g to return twice its arg but rather (+ arg 3).
While
(defun g (n)
((lambda (x) (+ x n)) n))
will get the n closed each time.
The key concept here is, threefore, not function-ness per se
but execution time.
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > How about in this one?
> >
> > (defun redifine-foo-adder (n)
> > (defun foo (x) (+ n x)))
>
> I think you meant
>
> (defun rfa (n)
> (defun rfa-aux (x) (+ n x))
> #'rfa-aux)
Actually, I was trying to make the point that despite the fact that
FOO could be different functions at different times, differing only in
the captured environment, the FOO would still be the *name* of the
function. (I was thinking that someone might object to my FLET example
because the name FOO isn't usable outside the ADDER function. After
calling REDEFINE-FOO-ADDER at least once, you can say (foo 10)--I
assumed it'd be hard for someone to argue that FOO *isn't* the name of
the function that that expression calls.)
> I was going to do the same example, and I agree that the fact of the
> naming per se is a red herring.
>
> What is relevant is the time of execution.
>
> (defun f (...) ...)
> means approximately
> (setf (symbol-function 'f) #'(lambda (...) (block f ...)))
>
> so if you assume there are no intervening flets, so that
> (symbol-function 'f) and #'f are equivalent, then
>
> (defun f ...)
> #'f
>
> is the same as
>
> #'(lambda ...)
>
> But what is subtly different is that if the definition occurred at
> toplevel, then it was evaluated (closed) at 'load time', while if it
> is in a definition it is evaluated (closed) at 'execution time' of
> the function.
Yup.
> I sometimes call (lambda (x) x) an "anonymous function" and say that
> it is its own name.
I don't know if you read my original post in this thread (it was a
week or so ago) but that was the point I was making--that lambda
expressions can be thought of as a kind of function name. Though I
tried to get clever and make an argument for calling them "eponymous"
functions because they do have a name--themself. (If you see what I
mean.)
> This is why it is allowed in FUNCTION forms. (function name) can be
> (FUNCTION CAR) or (FUNCTION (LAMBDA (X) X)). Likewise it's why you
> can say (CAR X) or ((LAMBDA (X) X) 3) because the car of a form is a
> function name.
Agreed. (Well, *I* agree. Steve Haflich, may not.)
> HOWEVER, doing this glosses the fact that it's constantly getting
> reconsidered in meaning. That is,
>
> (let ((n 3))
> (defun f (x) (+ x n)))
>
> closes F at load time. So
>
> (defun g (n)
> (f n))
>
> does not define g to return twice its arg but rather (+ arg 3).
> While
>
> (defun g (n)
> ((lambda (x) (+ x n)) n))
>
> will get the n closed each time.
>
> The key concept here is, threefore, not function-ness per se
> but execution time.
Yup.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Kent M Pitman <······@world.std.com> writes:
> I sometimes call (lambda (x) x) an "anonymous function" and say that it is
> its own name. This is why it is allowed in FUNCTION forms.
> (function name)
> can be (FUNCTION CAR) or (FUNCTION (LAMBDA (X) X)). Likewise it's why you
> can say (CAR X) or ((LAMBDA (X) X) 3) because the car of a form is a
> function name. HOWEVER, doing this glosses the fact that it's constantly
> getting reconsidered in meaning. That is,
I have another question relating to this issue. Someone wrote that
lambda in (lambda (x) x) is a macro, which expands to a function
object. Consider this:
[17]> (macroexpand '(lambda (x) x))
#'(LAMBDA (X) X) ;
T
[18]> (macroexpand '((lambda (x) x) 3))
((LAMBDA (X) X) 3) ;
NIL
[19]> (macroexpand '(funcall (lambda (x) x) 3))
(FUNCALL (LAMBDA (X) X) 3) ;
NIL
Why does lambda only get expanded in the first instance?
Bj�rn
·······@nada.kth.se (Bj�rn Lindberg) writes:
> I have another question relating to this issue. Someone wrote that
> lambda in (lambda (x) x) is a macro, which expands to a function
> object. Consider this:
>
> [17]> (macroexpand '(lambda (x) x))
> #'(LAMBDA (X) X) ;
> T
> [18]> (macroexpand '((lambda (x) x) 3))
> ((LAMBDA (X) X) 3) ;
> NIL
> [19]> (macroexpand '(funcall (lambda (x) x) 3))
> (FUNCALL (LAMBDA (X) X) 3) ;
> NIL
>
> Why does lambda only get expanded in the first instance?
Macroexpand expands based on the form's operator, i.e. it's car. The
first form is a macro form because lambda is a defined to be a macro,
and so it gets expanded. The second form is a "lambda form" (HS
sec. 3.1.2.1.2.4), i.e. a function application where the function is
not given by name but by a lambda expression. No macros involved. In
the third case, funcall is not a macro operator, so that's that for
macroexpand.
That is, macroexpand doesn't expand the form's sub-forms (in this
case, the arguments to funcall). If it did, consider what would have
happened to your first example:
(macroexpand '(lambda (x) x))
would yield
(function (lambda (x) x))
would yield
(function (function (lambda (x) x)))
would yield
(function (function (function (lambda (x) x))))
...and so on, forever, illustrating the point that whether some part
of a form is a macro (sub-)form depends also on the surrounding
context, not just whether the car is a macro operator. I.e. since
(function (lambda (x) x)) is a special form (function being a special
operator), the lambda part is _not_ a macro form. Rather, the lambda
expression in this case is used to invoke a particular aspect of
function's special behavior (to create a lexical closure), as
described in the HS entry for the function special operator.
--
Frode Vatvedt Fjeld
·······@nada.kth.se (Bj�rn Lindberg) wrote in message news:<···············@tjatte.nada.kth.se>...
> I have another question relating to this issue. Someone wrote that
> lambda in (lambda (x) x) is a macro, which expands to a function
> object.
Whether or not (lambda (x) x) is a macro call depends on context.
> Consider this:
>
> [17]> (macroexpand '(lambda (x) x))
> #'(LAMBDA (X) X) ;
> T
> [18]> (macroexpand '((lambda (x) x) 3))
> ((LAMBDA (X) X) 3) ;
> NIL
> [19]> (macroexpand '(funcall (lambda (x) x) 3))
> (FUNCALL (LAMBDA (X) X) 3) ;
> NIL
>
> Why does lambda only get expanded in the first instance?
Because in the second example, the expression is not a macro, but
serves in place of a function name. In the third example, it is macro,
but MACROEXPAND does not perform a full recursive macro-expansion of
all of the constituents of a form.
··········@yahoo.com (Willy) wrote in message news:<····························@posting.google.com>...
> 1. (funcall #'(lambda (x) (char= #\a x)) #\a)
> and
>
> 2. (funcall (lambda (x) (char= #\a x)) #\a)
People trying to learn Lisp are faced with
thousands of issues such as the above, and
think they have to understand each of them
before proceeding. That adds up to a huge
wall of confusion acting as an obstacle to
learning.
What is needed is a rule of thumb book, to
tell beginners what issues they can ignore
till later while proceeding to learn fast.
It would have rules of thumb in it such as
to always use (lambda ...) and not bother
to use #'(lambda ...). There is no need to
understand the difference before learning
enough Lisp to do significant work with it.
Rules of thumb are extremely important in
learning anything complicated, because you
can't learn everything at once, and you have
to be able to use what you're learning to
get enough experience to learn it well. The
subtle academic details gradually fall into
place as you gain more and more expertise.
But in cases where the above issue is being
explained to a beginner for whatever reason,
the best explanation is probably that when
macro expansion is finished the above two
forms are identical to each other. And if
they want to know how the macro expansion
proceeds, the first thing to understand is
that the argument to #' does not get macro
expanded because #' does not evaluate its
argument. And when the lambda without the
#' gets macro expanded, it becomes identical
to the one with the #'. Therefore the two
forms are identical after macro expansion.
From: Joerg-Cyril Hoehle
Subject: Re: what diff #'(lambda...) to (lambda...)?
Date:
Message-ID: <uwuf2h8uw.fsf@T-Systems.com>
········@yahoo.com (Eric Smith) writes:
> > 1. (funcall #'(lambda (x) (char= #\a x)) #\a)
> > 2. (funcall (lambda (x) (char= #\a x)) #\a)
> forms are identical to each other. And if
> they want to know how the macro expansion
> proceeds, the first thing to understand is
> that the argument to #' does not get macro
> expanded because #' does not evaluate its
> argument. And when the lambda without the
I disagree. Strictly #' - which really is a shortcut (more precisely,
a reader macro) for FUNCTION --
1. == 3. (funcall (FUNCTION (lambda (x) (char= #\a x))) #\a)
is a special operator and turns its argument into a closure or
function. As such, the argument is sort of evaluated. Of course, this
"evaluation" is different from the classic evaluation of Lisp forms.
> #' gets macro expanded, it becomes identical
> to the one with the #'. Therefore the two
> forms are identical after macro expansion.
*When* it gets expanded, if ever.
I believe this difference would help to understand why it would
probably be an error in beginners code if #' were to appear in quoted
lists, e.g.
(defparameter *data-driven*
'((grep #'(lambda (x y) ...)) ; probably wrong!
(addn #'(lambda (z) ...)))) ; probably wrong!
because no function object is constructed/generated here -- it's just
a pure tree of symbols, which is very different from
(defparameter *data-driven*
`( ; note backquote, not quote here
(grep ,#'(lambda (x y) ...))
(addn ,#'(lambda (z) ...))))
which contains real function objects.
If people would not use #', then just from reading, assessing or
reviewing code containing:
(defparameter *data-driven*
'((grep (lambda (x y) ...)) ; probably wrong!
(addn (lambda (z) ...)))) ; probably wrong!
they maybe should have used instead:
(defparameter *data-driven*
`( ; note backquote, not quote here
(grep ,(lambda (x y) ...))
(addn ,(lambda (z) ...))))
Regards,
Joerg Hoehle
TSI ITC-Security Technologiezentrum
Joerg-Cyril Hoehle <······@users.sourceforge.net> wrote in message news:<·············@T-Systems.com>...
> I disagree. Strictly #' - which really is a shortcut (more precisely,
The message you responded to was about
explaining it to beginners. There are
a lot of subtle details of Lisp which
beginners learn in stages. In their
early stages of learning, they don't
need to understand reader macros. It's
enough to just tell them #'foo is an
abbreviation for (function foo), and
that whenever we discuss it in terms of
the abbreviation they should understand
it to mean the same thing as the full
form, and that they can use either form
when actually using Lisp, with the same
results regardless.
Beginners don't know what to learn first.
From their point of view, the distinction
between (lambda ...) and #'(lambda ...)
seems just as important as the distinction
between a function and a closure. They
need someone to tell them that some issues
are a lot more important for them to learn
sooner than others.
For issues such as the distinction between
(lambda ...) and #'(lambda ...) we can just
give them rules of thumb, e.g. to always
use (lambda ...) and ignore #'(lambda ...)
as not being of interest to beginners. It's
to get them started faster, learning the more
important stuff, and not get bogged down in
subtle academic details that don't have any
practical value to beginners.