Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using #' with lambda
151 views
Skip to first unread message
Rupert Swarbrick
Apr 27, 2012, 10:34:14 AM4/27/12
to
Hi,
I'm looking at some existing code and the original author seems to use
the construct #'(lambda...) quite a lot. As far as I can understand,
this isn't required, because of how LAMBDA works as a macro (indeed, the
note at the bottom of its CLHS page seems to say this explicitly).
To be clear, the code does stuff like this:
(find 1 '((1 2) (3 4)) :key #'(lambda (x) (car x)))
(yes, I know I could use #'car here).
If I've understood correctly, this isn't required. (Please correct me if
I'm wrong!) But I was wondering if someone here knows of some ancient
system / lisp dialect where this would have made a difference?
The author of the code in question is clearly very competent, so I was
wondering what inspired him/her to use what I *think* is a two-character
no-op. One thing I wondered about was if it was to make the lambda form
stand out in a similar way to named functions:
(find 17 '((1 2) (4 3))
:key #'car
:test #'(lambda (a b) (eq (oddp a) (oddp b))))
But I don't really see why you'd bother... Lack of syntax highlighting?
Ideas?
Rupert
I'm looking at some existing code and the original author seems to use
the construct #'(lambda...) quite a lot. As far as I can understand,
this isn't required, because of how LAMBDA works as a macro (indeed, the
note at the bottom of its CLHS page seems to say this explicitly).
To be clear, the code does stuff like this:
(find 1 '((1 2) (3 4)) :key #'(lambda (x) (car x)))
(yes, I know I could use #'car here).
If I've understood correctly, this isn't required. (Please correct me if
I'm wrong!) But I was wondering if someone here knows of some ancient
system / lisp dialect where this would have made a difference?
The author of the code in question is clearly very competent, so I was
wondering what inspired him/her to use what I *think* is a two-character
no-op. One thing I wondered about was if it was to make the lambda form
stand out in a similar way to named functions:
(find 17 '((1 2) (4 3))
:key #'car
:test #'(lambda (a b) (eq (oddp a) (oddp b))))
But I don't really see why you'd bother... Lack of syntax highlighting?
Ideas?
Rupert
Zach Beane
Apr 27, 2012, 10:51:19 AM4/27/12
to
it felt/looked more like a reference to a function a la #'car, as you
mention above.
After a while, though, I just started writing (lambda ...) instead and
now prefer it.
In the rare situation where LAMBDA is in the car of a form, you can't
use #', but otherwise, I can't think of anything except aesthetic
preference to use one form or the other.
Zach
Barry Margolin
Apr 27, 2012, 10:58:01 AM4/27/12
to
In article <87ipglx...@aliengleams.portland.xach.com>,
Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
was required.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Zach Beane <xa...@xach.com> wrote:
> In the rare situation where LAMBDA is in the car of a form, you can't
> use #', but otherwise, I can't think of anything except aesthetic
> preference to use one form or the other.
For some people it just may be an old habit that they never got rid of.
> In the rare situation where LAMBDA is in the car of a form, you can't
> use #', but otherwise, I can't think of anything except aesthetic
> preference to use one form or the other.
Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
was required.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Rupert Swarbrick
Apr 27, 2012, 11:18:53 AM4/27/12
to
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <87ipglx...@aliengleams.portland.xach.com>,
> Zach Beane <xa...@xach.com> wrote:
>
>> In the rare situation where LAMBDA is in the car of a form, you can't
>> use #', but otherwise, I can't think of anything except aesthetic
>> preference to use one form or the other.
>
> For some people it just may be an old habit that they never got rid of.
> Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
> was required.
Ahah! That makes sense - I wondered whether it was something like
> In article <87ipglx...@aliengleams.portland.xach.com>,
> Zach Beane <xa...@xach.com> wrote:
>
>> In the rare situation where LAMBDA is in the car of a form, you can't
>> use #', but otherwise, I can't think of anything except aesthetic
>> preference to use one form or the other.
>
> For some people it just may be an old habit that they never got rid of.
> Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
> was required.
that.
Thank you both,
Rupert
Pascal Costanza
Apr 28, 2012, 5:26:35 PM4/28/12
to
On 27/04/2012 16:58, Barry Margolin wrote:
> In article<87ipglx...@aliengleams.portland.xach.com>,
> Zach Beane<xa...@xach.com> wrote:
>
>> In the rare situation where LAMBDA is in the car of a form, you can't
>> use #', but otherwise, I can't think of anything except aesthetic
>> preference to use one form or the other.
>
> For some people it just may be an old habit that they never got rid of.
> Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
> was required.
Wasn't the LAMBDA macro even a late addition to the Common Lisp
> In article<87ipglx...@aliengleams.portland.xach.com>,
> Zach Beane<xa...@xach.com> wrote:
>
>> In the rare situation where LAMBDA is in the car of a form, you can't
>> use #', but otherwise, I can't think of anything except aesthetic
>> preference to use one form or the other.
>
> For some people it just may be an old habit that they never got rid of.
> Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
> was required.
standard? I'm pretty sure that CLtL2 doesn't even have it...
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/
The views expressed are my own, and not those of my employer.
D Herring
Apr 28, 2012, 8:29:43 PM4/28/12
to
On 04/28/2012 05:26 PM, Pascal Costanza wrote:
> On 27/04/2012 16:58, Barry Margolin wrote:
>> In article<87ipglx...@aliengleams.portland.xach.com>,
>> Zach Beane<xa...@xach.com> wrote:
>>
>>> In the rare situation where LAMBDA is in the car of a form, you can't
>>> use #', but otherwise, I can't think of anything except aesthetic
>>> preference to use one form or the other.
>>
>> For some people it just may be an old habit that they never got rid of.
>> Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
>> was required.
>
> Wasn't the LAMBDA macro even a late addition to the Common Lisp
> standard? I'm pretty sure that CLtL2 doesn't even have it...
According to "Common Lisp: The Untold Story" by Kent Pitman (presented
> On 27/04/2012 16:58, Barry Margolin wrote:
>> In article<87ipglx...@aliengleams.portland.xach.com>,
>> Zach Beane<xa...@xach.com> wrote:
>>
>>> In the rare situation where LAMBDA is in the car of a form, you can't
>>> use #', but otherwise, I can't think of anything except aesthetic
>>> preference to use one form or the other.
>>
>> For some people it just may be an old habit that they never got rid of.
>> Most dialects prior to Common Lisp didn't have the LAMBDA macro, so #'
>> was required.
>
> Wasn't the LAMBDA macro even a late addition to the Common Lisp
> standard? I'm pretty sure that CLtL2 doesn't even have it...
at Lisp50), both the LAMBDA macro and DEFINE-SYMBOL-MACRO were added
to CL because he found they were needed to emulate ISLISP in Symbolics
Common Lisp. This all happened some time after Symbolics went
bankrupt in 1992.
- Daniel
Tim Bradshaw
Apr 29, 2012, 3:14:17 AM4/29/12
to
On 2012-04-28 21:26:35 +0000, Pascal Costanza said:
> Wasn't the LAMBDA macro even a late addition to the Common Lisp
> standard? I'm pretty sure that CLtL2 doesn't even have it...
Yes, it was late. I think it was added to provide infrastructure to
> Wasn't the LAMBDA macro even a late addition to the Common Lisp
> standard? I'm pretty sure that CLtL2 doesn't even have it...
let you implement some other Lisp standard in CL: the problem being
that if you don't have a macro such that (lambda ...) -> (function
(lambda ...)) you can't conformingly write one because LAMBDA is in the
CL package.
Kaz Kylheku
Apr 29, 2012, 10:36:40 AM4/29/12
to
LIST is in the CL package, yet we can use it as as a variable name.
Barry Margolin
Apr 29, 2012, 12:24:09 PM4/29/12
to
In article <201204290...@kylheku.com>,
You can use it as a local variable, but not a global one.
The rationale is that local bindings don't interfere with each other,
but if two applications tried to create global bindings on the same
symbol they would conflict.
The rationale is that local bindings don't interfere with each other,
but if two applications tried to create global bindings on the same
symbol they would conflict.
Pascal J. Bourguignon
Apr 29, 2012, 2:04:26 PM4/29/12
to
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <201204290...@kylheku.com>,
> Kaz Kylheku <k...@kylheku.com> wrote:
>
>> On 2012-04-29, Tim Bradshaw <t...@tfeb.org> wrote:
>> > On 2012-04-28 21:26:35 +0000, Pascal Costanza said:
>> >
>> >> Wasn't the LAMBDA macro even a late addition to the Common Lisp
>> >> standard? I'm pretty sure that CLtL2 doesn't even have it...
>> >
>> > Yes, it was late. I think it was added to provide infrastructure to
>> > let you implement some other Lisp standard in CL: the problem being
>> > that if you don't have a macro such that (lambda ...) -> (function
>> > (lambda ...)) you can't conformingly write one because LAMBDA is in the
>> > CL package.
>>
>> What? Even though it has no binding if such a macro doesn't exist?
>> LIST is in the CL package, yet we can use it as as a variable name.
>
> You can use it as a local variable, but not a global one.
>
> The rationale is that local bindings don't interfere with each other,
> but if two applications tried to create global bindings on the same
> symbol they would conflict.
Furthermore the fbinding of symbols in the CL packages are reserved to
> In article <201204290...@kylheku.com>,
> Kaz Kylheku <k...@kylheku.com> wrote:
>
>> On 2012-04-29, Tim Bradshaw <t...@tfeb.org> wrote:
>> > On 2012-04-28 21:26:35 +0000, Pascal Costanza said:
>> >
>> >> Wasn't the LAMBDA macro even a late addition to the Common Lisp
>> >> standard? I'm pretty sure that CLtL2 doesn't even have it...
>> >
>> > Yes, it was late. I think it was added to provide infrastructure to
>> > let you implement some other Lisp standard in CL: the problem being
>> > that if you don't have a macro such that (lambda ...) -> (function
>> > (lambda ...)) you can't conformingly write one because LAMBDA is in the
>> > CL package.
>>
>> What? Even though it has no binding if such a macro doesn't exist?
>> LIST is in the CL package, yet we can use it as as a variable name.
>
> You can use it as a local variable, but not a global one.
>
> The rationale is that local bindings don't interfere with each other,
> but if two applications tried to create global bindings on the same
> symbol they would conflict.
the implementation: there very possibly was implementations already
using it for their purpose.
See 11.1.2.1.2 for details.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Tim Bradshaw
Apr 29, 2012, 3:48:53 PM4/29/12
to
On 2012-04-29 14:36:40 +0000, Kaz Kylheku said:
> What? Even though it has no binding if such a macro doesn't exist?
> LIST is in the CL package, yet we can use it as as a variable name.
Yes. You can lexically bind such symbols (including as functions or
> What? Even though it has no binding if such a macro doesn't exist?
> LIST is in the CL package, yet we can use it as as a variable name.
macros), but that's about it.
Kaz Kylheku
Apr 29, 2012, 3:53:15 PM4/29/12
to
On 2012-04-29, Tim Bradshaw <t...@tfeb.org> wrote:
or global function called finally. Hmm.
--
If you ever need any coding done, I'm your goto man!
Barry Margolin
Apr 29, 2012, 4:21:25 PM4/29/12
to
In article <201204291...@kylheku.com>,
there's not much problem with the variable restriction.
One of the reasons that loop keywords are compared by namestring, not
symbol equality, may be so that we wouldn't pollute the CL package with
symbols like IN, TO, FOR, FROM, etc.
Kaz Kylheku <k...@kylheku.com> wrote:
> On 2012-04-29, Tim Bradshaw <t...@tfeb.org> wrote:
> > On 2012-04-29 14:36:40 +0000, Kaz Kylheku said:
> >
> >> What? Even though it has no binding if such a macro doesn't exist?
> >> LIST is in the CL package, yet we can use it as as a variable name.
> >
> > Yes. You can lexically bind such symbols (including as functions or
> > macros), but that's about it.
>
> So if loop keywords were CL symbols, you couldn't have dynamic variable
> or global function called finally. Hmm.
Since dynamic variables are supposed to following the *name* convention,
> On 2012-04-29, Tim Bradshaw <t...@tfeb.org> wrote:
> > On 2012-04-29 14:36:40 +0000, Kaz Kylheku said:
> >
> >> What? Even though it has no binding if such a macro doesn't exist?
> >> LIST is in the CL package, yet we can use it as as a variable name.
> >
> > Yes. You can lexically bind such symbols (including as functions or
> > macros), but that's about it.
>
> So if loop keywords were CL symbols, you couldn't have dynamic variable
> or global function called finally. Hmm.
there's not much problem with the variable restriction.
One of the reasons that loop keywords are compared by namestring, not
symbol equality, may be so that we wouldn't pollute the CL package with
symbols like IN, TO, FOR, FROM, etc.
Tim Bradshaw
Apr 30, 2012, 5:43:52 AM4/30/12
to
On 2012-04-29 19:53:15 +0000, Kaz Kylheku said:
> So if loop keywords were CL symbols, you couldn't have dynamic variable
> or global function called finally. Hmm.
Or implement a macro called FOR, for instance. It would be a pain.
> So if loop keywords were CL symbols, you couldn't have dynamic variable
> or global function called finally. Hmm.
Pascal J. Bourguignon
Apr 30, 2012, 6:27:42 AM4/30/12
to
Tim Bradshaw
Apr 30, 2012, 7:21:54 AM4/30/12
to
On 2012-04-30 10:27:42 +0000, Pascal J. Bourguignon said:
> Hence my habit of using keywords in LOOP.
That doesn't follow. Well, I suppose it would follow in the case where
> Hence my habit of using keywords in LOOP.
the current package was CL I guess, but otherwise it doesn't (and even
then it would only follow if you then exported the symbol from CL,
which would, I think, not be conforming).
0 new messages