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).
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?
> 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).
> 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?
I can't comment on why this author did it, but I used to do it because
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.
In article <87ipglxm6w....@aliengleams.portland.xach.com>,
Zach Beane <x...@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.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <87ipglxm6w....@aliengleams.portland.xach.com>,
> Zach Beane <x...@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
that.
> In article<87ipglxm6w....@aliengleams.portland.xach.com>,
> Zach Beane<x...@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...
> On 27/04/2012 16:58, Barry Margolin wrote:
>> In article<87ipglxm6w....@aliengleams.portland.xach.com>,
>> Zach Beane<x...@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 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.
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.
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.
In article <20120429072356....@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.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <20120429072356....@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
the implementation: there very possibly was implementations already
using it for their purpose.
In article <20120429123320....@kylheku.com>,
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, 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.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
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 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).
