From: Stefan Arentz
Subject: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <87u02qydm2.fsf@kip.sateh.com>
I finally got my copy of Practical Common Lisp so I'm going over the first
few chapters again. Great stuff but questions keep popping up. I hope this
group doesn't mind :-)
Here is a simple one. In chapter3 there is the following code
(remove-if-not #'evenp (list 1 2 3 4 5))
(remove-if-not #'(lambda (x) (= 0 (mod x 2))) (list 1 2 3 4 5))
I understand why in the first case #' is used as it is a shortcut for
(function 'evenp) right? But why does the author also use it for the
lambda result? With and without it evaluates to the same:
CL-USER> (lambda (x) (= 0 (mod x 2)))
#<Interpreted Function (unnamed) @ #x1057da32>
CL-USER> #'(lambda (x) (= 0 (mod x 2)))
#<Interpreted Function (unnamed) @ #x1057fe32>
Is it just convention or is there more to it?
S.
Stefan Arentz <·············@gmail.com> writes:
> I finally got my copy of Practical Common Lisp so I'm going over the first
> few chapters again. Great stuff but questions keep popping up. I hope this
> group doesn't mind :-)
>
> Here is a simple one. In chapter3 there is the following code
>
> (remove-if-not #'evenp (list 1 2 3 4 5))
>
> (remove-if-not #'(lambda (x) (= 0 (mod x 2))) (list 1 2 3 4 5))
>
> I understand why in the first case #' is used as it is a shortcut for
> (function 'evenp) right? But why does the author also use it for the
> lambda result? With and without it evaluates to the same:
>
> CL-USER> (lambda (x) (= 0 (mod x 2)))
> #<Interpreted Function (unnamed) @ #x1057da32>
>
> CL-USER> #'(lambda (x) (= 0 (mod x 2)))
> #<Interpreted Function (unnamed) @ #x1057fe32>
>
> Is it just convention or is there more to it?
>
> S.
There is no semantic difference between the two. It's a matter of
personal preference. In Scheme, lambda is a special form, so the
implementation creates a closure when it evaluates it. In Common
Lisp, an anonymous function technically has to be created with the
(function (lambda ...)) idiom, since FUNCTION is a special form.
since #' is a read-macro for (function ...), #'(lambda ...) is the
same as (function (lambda ...)). To save Lispers from two extra
characters of typing, Common Lisp specified that LAMBDA is a macro
that expands to (function (lambda ...)). So whether you write (lambda
...) or #'(lambda ...), both are internally converted to (function
(lambda ...)), so they have the same meaning.
Some people use #' for consistency; other people leave it off to save
typing.
Bill
From: Kalle Olavi Niemitalo
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <87odsy30ia.fsf@Astalo.kon.iki.fi>
Bill Atkins <······@rpi.edu> writes:
> To save Lispers from two extra characters of typing, Common Lisp
> specified that LAMBDA is a macro that expands to (function (lambda ...)).
Issue ISO-COMPATIBILITY suggests a different reason.
http://clhs.lisp.se/Issues/iss198_w.htm
From: Ken Tilton
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <ijeTg.648$RJ3.625@newsfe08.lga>
Stefan Arentz wrote:
> I finally got my copy of Practical Common Lisp so I'm going over the first
> few chapters again. Great stuff but questions keep popping up. I hope this
> group doesn't mind :-)
>
> Here is a simple one. In chapter3 there is the following code
>
> (remove-if-not #'evenp (list 1 2 3 4 5))
>
> (remove-if-not #'(lambda (x) (= 0 (mod x 2))) (list 1 2 3 4 5))
>
> I understand why in the first case #' is used as it is a shortcut for
> (function 'evenp) right?
(remove-if-not 'evenp ...) also works.
There is a subtle difference, I just forget. Something about if the
function exists when the code gets compiled?
Anyway, that might change your question a little.
> But why does the author also use it for the
> lambda result? With and without it evaluates to the same:
>
> CL-USER> (lambda (x) (= 0 (mod x 2)))
> #<Interpreted Function (unnamed) @ #x1057da32>
>
> CL-USER> #'(lambda (x) (= 0 (mod x 2)))
> #<Interpreted Function (unnamed) @ #x1057fe32>
>
> Is it just convention or is there more to it?
Well, the /macro/ lambda, according to clhs:
"Provides a shorthand notation for a function special form involving a
lambda expression such that:
(lambda lambda-list [[{declaration}* | documentation]] {form}*)
==(function (lambda lambda-list [[{declaration}* | documentation]]
{form}*))
==#'(lambda lambda-list [[{declaration}* | documentation]] {form}*)"
I wrote #'(lambda ...) for eons before discovering it was unnecessary.
So Peter either was in the same boat (was it in an early chapter? Peter
was learning Lisp (partly here on c.l.l before I turned it into a
cesspool) as he went, which was pretty cool to watch) or did not want to
complicate things for pedagogic reasons.
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
In article <·················@newsfe08.lga>,
Ken Tilton <·········@gmail.com> wrote:
> Stefan Arentz wrote:
> > I finally got my copy of Practical Common Lisp so I'm going over the first
> > few chapters again. Great stuff but questions keep popping up. I hope this
> > group doesn't mind :-)
> >
> > Here is a simple one. In chapter3 there is the following code
> >
> > (remove-if-not #'evenp (list 1 2 3 4 5))
> >
> > (remove-if-not #'(lambda (x) (= 0 (mod x 2))) (list 1 2 3 4 5))
> >
> > I understand why in the first case #' is used as it is a shortcut for
> > (function 'evenp) right?
>
> (remove-if-not 'evenp ...) also works.
>
> There is a subtle difference, I just forget. Something about if the
> function exists when the code gets compiled?
The subtle difference comes up when the function is in a variable and
the function is redefined after assigning to the variable.
(defvar *test-function-1*)
(defvar *test-function-2*)
(defun test-fun ()
'old)
(setq *test-function-1* 'test-fun)
(setq *test-function-2* #'test-fun)
(defun test-fun ()
'new)
(funcall *test-function-1*) => NEW
(funcall *test-function-2*) => OLD
*TEST-FUNCTION-1* contains the function's name, so it always gets the
current definition of that name. *TEST-FUNCTION-2* contains the
function object itself; when function is redefined, a new function is
created and associated with the name, but this has no effect on
references to the old function.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <87d59cxey5.fsf@qrnik.zagroda>
Barry Margolin <······@alum.mit.edu> writes:
>> (remove-if-not 'evenp ...) also works.
>>
>> There is a subtle difference, I just forget. Something about if the
>> function exists when the code gets compiled?
>
> The subtle difference comes up when the function is in a variable and
> the function is redefined after assigning to the variable.
Another difference is that #'evenp can access a local function
(defined by flet or labels), while 'evenp is always interpreted
as the global function.
Also it is more likely that #'evenp will catch a misspelled function
name early than 'evenp.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Stefan Arentz <·············@gmail.com> writes:
> I finally got my copy of Practical Common Lisp so I'm going over the first
> few chapters again. Great stuff but questions keep popping up. I hope this
> group doesn't mind :-)
>
> Here is a simple one. In chapter3 there is the following code
>
> (remove-if-not #'evenp (list 1 2 3 4 5))
>
> (remove-if-not #'(lambda (x) (= 0 (mod x 2))) (list 1 2 3 4 5))
>
> I understand why in the first case #' is used as it is a shortcut for
> (function 'evenp) right?
Not exactly. It's a shortcut for: (function evenp)
(defun print-list-items (list)
(if (listp list)
(dolist (item list (values))
(print item))
(error "~S is not a list, it's a ~S" list (type-of list))))
(print-list-items '#'evenp)
prints:
FUNCTION
EVENP
> But why does the author also use it for the
> lambda result?
Because he likes redundancy?
Or because he doesn't trust his lisp implementation?
Or because he's an old hand encrusted into his habits? (I'm like this
sometimes too).
One problem is that some implementation like to print lists containing
cl:function as first element using this shortcut syntax:
(macroexpand-1 '(lambda (x) (= 0 (mod x 2))))
--> #'(LAMBDA (X) (= 0 (MOD X 2))) ;
T
But what we really have here, is a list:
(print-list-items (macroexpand-1 '(lambda (x) (= 0 (mod x 2)))))
FUNCTION
(LAMBDA (X) (= 0 (MOD X 2)))
This is because lambda is a macro that expands (lambda ...)
to (function (lambda ...)).
What happens, is that once upon a time, before the CL standard was
finished, there was some limbic language where lambda wasn't a macro,
and you had to write explicitely (function (lambda ...)) in it.
People who used this language tend to keep writting (function (lambda
...)) everywhere (and are thankfull for the ugly #').
> With and without it evaluates to the same:
You can observe a difference at macro expansion time though.
LISP> (setf *macroexpand-hook*
(lambda (macro-fun macro-form environment)
(format *trace-output* "~&Hey! I'm going to expand ~S~%" macro-form)
(finish-output *trace-output*)
(let ((result (funcall macro-fun macro-form environment)))
(format *trace-output* "~&Hey! It expanded to ~S~%" result)
(finish-output *trace-output*)
result)))
#<FUNCTION :LAMBDA (MACRO-FUN MACRO-FORM ENVIRONMENT)
(FORMAT *TRACE-OUTPUT* "~&Hey! I'm going to expand ~S~%" MACRO-FORM)
(FINISH-OUTPUT *TRACE-OUTPUT*)
(LET ((RESULT (FUNCALL MACRO-FUN MACRO-FORM ENVIRONMENT)))
(FORMAT *TRACE-OUTPUT* "~&Hey! It expanded to ~S~%" RESULT)
(FINISH-OUTPUT *TRACE-OUTPUT*) RESULT)>
LISP> (lambda (x) (= 0 (mod x 2)))
Hey! I'm going to expand (LAMBDA (X) (= 0 (MOD X 2)))
Hey! It expanded to #'(LAMBDA (X) (= 0 (MOD X 2)))
#<FUNCTION :LAMBDA (X) (= 0 (MOD X 2))>
LISP> (function (lambda (x) (= 0 (mod x 2))))
#<FUNCTION :LAMBDA (X) (= 0 (MOD X 2))>
In the former case, the macro function is called (and the macroexpand
hook too), while in the later case it is not.
> Is it just convention or is there more to it?
LISP> (dotimes (i 3) (princ "Ni! "))
Hey! I'm going to expand (DOTIMES (I 3) (PRINC "Ni! "))
Hey! It expanded to (DO ((I 0 (1+ I))) ((>= I 3) NIL) (PRINC "Ni! "))
Hey! I'm going to expand (DO ((I 0 (1+ I))) ((>= I 3) NIL) (PRINC "Ni! "))
Hey! It expanded to
(BLOCK NIL
(LET ((I 0))
(TAGBODY #:G17160 (IF (>= I 3) (GO #:G17161)) (PRINC "Ni! ") (PSETQ I (1+ I))
(GO #:G17160) #:G17161 (RETURN-FROM NIL (PROGN NIL)))))
Ni! Ni! Ni!
NIL
LISP> (setf *macroexpand-hook* (function funcall))
Hey! I'm going to expand (SETF *MACROEXPAND-HOOK* #'FUNCALL)
Hey! It expanded to (SETQ *MACROEXPAND-HOOK* #'FUNCALL)
#<SYSTEM-FUNCTION FUNCALL>
LISP>
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais �t�: �Qui suis-je? O� vais-je?�
comme l'a formul� si adroitement notre ami Pascal, mais plut�t:
�Comment vais-je m'en tirer?� -- Jean Yanne
From: Marcus Breiing
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <efjb6j$e2b$1@chessie.cirr.com>
Stefan Arentz <·············@gmail.com> writes:
> CL-USER> (lambda (x) (= 0 (mod x 2)))
> #<Interpreted Function (unnamed) @ #x1057da32>
>
> CL-USER> #'(lambda (x) (= 0 (mod x 2)))
> #<Interpreted Function (unnamed) @ #x1057fe32>
>
> Is it just convention or is there more to it?
Technically, the first is a macro-call that expands into the second.
There is one practical difference that I'm currently aware of, which
is that, should you ever want to work with a shadowed version of
lambda (using packages), the first will work (because you can provide
a macro definition for your-package:lambda), the second won't (because
that form is hardwired for cl:lambda).
--
Marcus Breiing
(Cologne, Germany)
From: Stefan Arentz
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <87psdeyc0t.fsf@kip.sateh.com>
Marcus Breiing <······@2006w38.mail.breiing.com> writes:
> Stefan Arentz <·············@gmail.com> writes:
>
> > CL-USER> (lambda (x) (= 0 (mod x 2)))
> > #<Interpreted Function (unnamed) @ #x1057da32>
> >
> > CL-USER> #'(lambda (x) (= 0 (mod x 2)))
> > #<Interpreted Function (unnamed) @ #x1057fe32>
> >
> > Is it just convention or is there more to it?
>
> Technically, the first is a macro-call that expands into the second.
>
> There is one practical difference that I'm currently aware of, which
> is that, should you ever want to work with a shadowed version of
> lambda (using packages), the first will work (because you can provide
> a macro definition for your-package:lambda), the second won't (because
> that form is hardwired for cl:lambda).
You mean the macro contains the package namespace in it's closure?
(I'm probably using the wrong terms :)
S.
Stefan Arentz <·············@gmail.com> writes:
> Marcus Breiing <······@2006w38.mail.breiing.com> writes:
>
>> Stefan Arentz <·············@gmail.com> writes:
>>
>> > CL-USER> (lambda (x) (= 0 (mod x 2)))
>> > #<Interpreted Function (unnamed) @ #x1057da32>
>> >
>> > CL-USER> #'(lambda (x) (= 0 (mod x 2)))
>> > #<Interpreted Function (unnamed) @ #x1057fe32>
>> >
>> > Is it just convention or is there more to it?
>>
>> Technically, the first is a macro-call that expands into the second.
>>
>> There is one practical difference that I'm currently aware of, which
>> is that, should you ever want to work with a shadowed version of
>> lambda (using packages), the first will work (because you can provide
>> a macro definition for your-package:lambda), the second won't (because
>> that form is hardwired for cl:lambda).
>
> You mean the macro contains the package namespace in it's closure?
Nope. All symbol objects in CL belong to a package. If you want to
extend LAMBDA for some reason, you define your lambda in a new package
and shadow CL:LAMBDA, i.e. the official lambda. Now if anyone uses
the form (lambda (foo bar) ...) in that package, they're actually
referring to your lambda. But if they use the form #'(lambda (foo
bar) ...) they are referring to CL:LAMBDA and your new implementation
never even knows. You could get around this by redefining the #'
macro and also shadowing FUNCTION - or by not messing with LAMBDA at
all. :-)
From: Stefan Arentz
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <87lko2yal3.fsf@kip.sateh.com>
Bill Atkins <······@rpi.edu> writes:
> Stefan Arentz <·············@gmail.com> writes:
>
> > Marcus Breiing <······@2006w38.mail.breiing.com> writes:
> >
> >> Stefan Arentz <·············@gmail.com> writes:
> >>
> >> > CL-USER> (lambda (x) (= 0 (mod x 2)))
> >> > #<Interpreted Function (unnamed) @ #x1057da32>
> >> >
> >> > CL-USER> #'(lambda (x) (= 0 (mod x 2)))
> >> > #<Interpreted Function (unnamed) @ #x1057fe32>
> >> >
> >> > Is it just convention or is there more to it?
> >>
> >> Technically, the first is a macro-call that expands into the second.
> >>
> >> There is one practical difference that I'm currently aware of, which
> >> is that, should you ever want to work with a shadowed version of
> >> lambda (using packages), the first will work (because you can provide
> >> a macro definition for your-package:lambda), the second won't (because
> >> that form is hardwired for cl:lambda).
> >
> > You mean the macro contains the package namespace in it's closure?
>
> Nope. All symbol objects in CL belong to a package. If you want to
> extend LAMBDA for some reason, you define your lambda in a new package
> and shadow CL:LAMBDA, i.e. the official lambda. Now if anyone uses
> the form (lambda (foo bar) ...) in that package, they're actually
> referring to your lambda. But if they use the form #'(lambda (foo
> bar) ...) they are referring to CL:LAMBDA and your new implementation
> never even knows. You could get around this by redefining the #'
> macro and also shadowing FUNCTION - or by not messing with LAMBDA at
> all. :-)
Clear. So #'(lambda ..) is actually bad style?
S.
Stefan Arentz <·············@gmail.com> writes:
> Bill Atkins <······@rpi.edu> writes:
>
>> Stefan Arentz <·············@gmail.com> writes:
>>
>> > Marcus Breiing <······@2006w38.mail.breiing.com> writes:
>> >
>> >> Stefan Arentz <·············@gmail.com> writes:
>> >>
>> >> > CL-USER> (lambda (x) (= 0 (mod x 2)))
>> >> > #<Interpreted Function (unnamed) @ #x1057da32>
>> >> >
>> >> > CL-USER> #'(lambda (x) (= 0 (mod x 2)))
>> >> > #<Interpreted Function (unnamed) @ #x1057fe32>
>> >> >
>> >> > Is it just convention or is there more to it?
>> >>
>> >> Technically, the first is a macro-call that expands into the second.
>> >>
>> >> There is one practical difference that I'm currently aware of, which
>> >> is that, should you ever want to work with a shadowed version of
>> >> lambda (using packages), the first will work (because you can provide
>> >> a macro definition for your-package:lambda), the second won't (because
>> >> that form is hardwired for cl:lambda).
>> >
>> > You mean the macro contains the package namespace in it's closure?
>>
>> Nope. All symbol objects in CL belong to a package. If you want to
>> extend LAMBDA for some reason, you define your lambda in a new package
>> and shadow CL:LAMBDA, i.e. the official lambda. Now if anyone uses
>> the form (lambda (foo bar) ...) in that package, they're actually
>> referring to your lambda. But if they use the form #'(lambda (foo
>> bar) ...) they are referring to CL:LAMBDA and your new implementation
>> never even knows. You could get around this by redefining the #'
>> macro and also shadowing FUNCTION - or by not messing with LAMBDA at
>> all. :-)
>
> Clear. So #'(lambda ..) is actually bad style?
Not at all - but shadowing LAMBDA is bad style except in special
circumstances.
Bill Atkins <······@rpi.edu> writes:
> Stefan Arentz <·············@gmail.com> writes:
>
>> Marcus Breiing <······@2006w38.mail.breiing.com> writes:
>>
>>> Stefan Arentz <·············@gmail.com> writes:
>>>
>>> > CL-USER> (lambda (x) (= 0 (mod x 2)))
>>> > #<Interpreted Function (unnamed) @ #x1057da32>
>>> >
>>> > CL-USER> #'(lambda (x) (= 0 (mod x 2)))
>>> > #<Interpreted Function (unnamed) @ #x1057fe32>
>>> >
>>> > Is it just convention or is there more to it?
>>>
>>> Technically, the first is a macro-call that expands into the second.
>>>
>>> There is one practical difference that I'm currently aware of, which
>>> is that, should you ever want to work with a shadowed version of
>>> lambda (using packages), the first will work (because you can provide
>>> a macro definition for your-package:lambda), the second won't (because
>>> that form is hardwired for cl:lambda).
>>
>> You mean the macro contains the package namespace in it's closure?
>
> Nope. All symbol objects in CL belong to a package. If you want to
> extend LAMBDA for some reason, you define your lambda in a new package
> and shadow CL:LAMBDA, i.e. the official lambda. Now if anyone uses
> the form (lambda (foo bar) ...) in that package, they're actually
> referring to your lambda. But if they use the form #'(lambda (foo
> bar) ...) they are referring to CL:LAMBDA and your new implementation
> never even knows.
Why should it? Of course it won't.
[249]> (defpackage :test (:use :cl))
#<PACKAGE TEST>
[250]> (in-package :test)
#<PACKAGE TEST>
TEST[251]> (shadow 'lambda)
T
TEST[252]> (function (lambda (x) (+ x 1)))
*** - FUNCTION: (LAMBDA (X) (+ X 1)) is not a function name; try using a symbol
instead
> You could get around this by redefining the #'
> macro and also shadowing FUNCTION - or by not messing with LAMBDA at
> all. :-)
Yes, you can solve your own problems...
I prefer to write (lambda ...) instead of (function ...) and avoid the
problem in the first place.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
Marcus Breiing <······@2006w38.mail.breiing.com> writes:
> Stefan Arentz <·············@gmail.com> writes:
>
>> CL-USER> (lambda (x) (= 0 (mod x 2)))
>> #<Interpreted Function (unnamed) @ #x1057da32>
>>
>> CL-USER> #'(lambda (x) (= 0 (mod x 2)))
>> #<Interpreted Function (unnamed) @ #x1057fe32>
>>
>> Is it just convention or is there more to it?
>
> Technically, the first is a macro-call that expands into the second.
>
> There is one practical difference that I'm currently aware of, which
> is that, should you ever want to work with a shadowed version of
> lambda (using packages), the first will work (because you can provide
> a macro definition for your-package:lambda), the second won't (because
> that form is hardwired for cl:lambda).
Not at all. Actually, this might be a strong point in favor of
(lambda ...) over #'(lambda ...):
(shadow 'lambda)
(defmacro lambda (args &body body)
(let ((real-args (process-args args))
(real-body (process-body body)))
`(cl:lambda ,real-args ,@real-body)))
(lambda (x) (* 2 x)) ; still works
#'(lambda (x) (* 2 x)) ; fails
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
From: Pascal Costanza
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <4o4rquFcs7bfU1@individual.net>
Pascal Bourguignon wrote:
> Marcus Breiing <······@2006w38.mail.breiing.com> writes:
>
>> Stefan Arentz <·············@gmail.com> writes:
>>
>>> CL-USER> (lambda (x) (= 0 (mod x 2)))
>>> #<Interpreted Function (unnamed) @ #x1057da32>
>>>
>>> CL-USER> #'(lambda (x) (= 0 (mod x 2)))
>>> #<Interpreted Function (unnamed) @ #x1057fe32>
>>>
>>> Is it just convention or is there more to it?
>> Technically, the first is a macro-call that expands into the second.
>>
>> There is one practical difference that I'm currently aware of, which
>> is that, should you ever want to work with a shadowed version of
>> lambda (using packages), the first will work (because you can provide
>> a macro definition for your-package:lambda), the second won't (because
>> that form is hardwired for cl:lambda).
>
> Not at all. Actually, this might be a strong point in favor of
> (lambda ...) over #'(lambda ...):
>
>
>
> (shadow 'lambda)
> (defmacro lambda (args &body body)
> (let ((real-args (process-args args))
> (real-body (process-body body)))
> `(cl:lambda ,real-args ,@real-body)))
>
> (lambda (x) (* 2 x)) ; still works
> #'(lambda (x) (* 2 x)) ; fails
Of course, you can also shadow 'function. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Marcus Breiing
Subject: Re: Difference between #'(lambda ...) and (lambda ...) ?
Date:
Message-ID: <efjofn$fpl$1@chessie.cirr.com>
Pascal Bourguignon <···@informatimago.com> writes:
> Marcus Breiing <······@2006w38.mail.breiing.com> writes:
> Not at all. Actually [...]
> (lambda (x) (* 2 x)) ; still works
> #'(lambda (x) (* 2 x)) ; fails
Which is what I wrote. What was your point?
(Hmm... possibly a mixup about what "the first"/"the second" were in
reference to. I meant to refer to the example lines I quoted, not the
subject line. That's it?)
--
Marcus Breiing
(Cologne, Germany)
Marcus Breiing <······@2006w38.mail.breiing.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>> Marcus Breiing <······@2006w38.mail.breiing.com> writes:
>
>> Not at all. Actually [...]
>
>> (lambda (x) (* 2 x)) ; still works
>> #'(lambda (x) (* 2 x)) ; fails
>
> Which is what I wrote. What was your point?
>
> (Hmm... possibly a mixup about what "the first"/"the second" were in
> reference to. I meant to refer to the example lines I quoted, not the
> subject line. That's it?)
Sorry, I don't know what I read in your post, and made the same point as you.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Pascal Bourguignon <···@informatimago.com> writes:
> Marcus Breiing <······@2006w38.mail.breiing.com> writes:
>
> > There is one practical difference that I'm currently aware of, which
> > is that, should you ever want to work with a shadowed version of
> > lambda (using packages), the first will work (because you can provide
> > a macro definition for your-package:lambda), the second won't (because
> > that form is hardwired for cl:lambda).
>
> Not at all. Actually, this might be a strong point in favor of
> (lambda ...) over #'(lambda ...):
Nuh-uh, no way. Unless you're half way to creating a new dialect
inside your CL image, it's very questionable style to shadow
cl:lambda. And if you're in so deep that you *are* shadowing lambda,
shadowing cl:function and writing a #' reader-macro isn't much work.
I think a much better argument is what happens when you write a
domain-specific lambda-like macro. clambda, xlambda, fn, nlambda,
whatever you call it, the need for these "it's just like lambda,
but..." macros come up from time to time. If you normally write
(lambda ...), your calls to clambda (or whatever) will seamlessly
blend into the surrounding code. If you normally write #'(lambda ...),
your lambda-like things stand out that little extra bit relative
to lambda.
But it's really a tiny, trivial issue of style that's hardly worth
bothering about, since neither style is per-se wrong or bad.
Personally I swtiched sides (to using bare (lambda ...)) when I
changed from using all-CL to a mixture of CL and other Lisps, mostly
as a way to reduce cognitive burden, since (lambda ...) works in all
modern Lisp dialects. Much like how I stopped writing
if (x == y) foo(); else bar();
in languages with C-inspired syntax so I wouldn't screw up and write
something like the above in a language that required curly braces
there. Now I prefer the (lambda ...) style just on aesthetics, but in
code bases where #'(lambda ...) is used consistently, I don't mind
adapting to the local style.