Hi,
the hyperspec says in 3.4.4 something about Macro Lambda Lists.
a) would you agree that (defmacro foo bar bar) is not allowed?
The Macro Lambda List is a list, so a single variable,
here BAR, is not allowed?
b) looking at the lambda-list production:
( . var ) would be valid?
But it makes no sense, right?
c) what is ( . symbol) anyway? Is it something the reader
should be able to read?
Rainer Joswig
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> wrote:
>Hi,
>
>the hyperspec says in 3.4.4 something about Macro Lambda Lists.
>
>a) would you agree that (defmacro foo bar bar) is not allowed?
> The Macro Lambda List is a list, so a single variable,
> here BAR, is not allowed?
Correct. The description of destructuring says that wherever a variable is
allowed and a list would not be, you can replace it with a list and it will
be destructured; it doesn't say you can go the other way and merge a list
into a single variable.
However, the logic of allowing the transformation in both directions makes
a little sense, so it doesn't seem like an unreasonable extension. You can
get the same effect with (defmacro foo (&rest bar) bar), but it might be
easier for program-generating programs to deal with the simpler form.
>b) looking at the lambda-list production:
>
> ( . var ) would be valid?
>
> But it makes no sense, right?
That's not valid list syntax at all, because of the answer to (c). So it
never gets processed as a lambda-list.
>c) what is ( . symbol) anyway? Is it something the reader
> should be able to read?
No. See section 2.4.1, where the syntax of lists is described. It says
"If a token that is just a dot ... is read after some object ...". In the
above case, the dot is not after an object, so it's not a consing dot. And
section 2.3.3 says that a token consisting entirely of dots signals an
error unless it's in the appropriate situation for a consing dot. So the
above notation must signal an error.
If that syntax were allowed, then the obvious meaning for it should be
equivalent to SYMBOL by itself. If CL didn't require an error to be
signaled then I suppose an implementation could support it as an extension
(it might fall out naturally from some algorithms for implementing the list
reader macro).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <················@burlma1-snr2>, Barry Margolin
<······@genuity.net> wrote:
> >the hyperspec says in 3.4.4 something about Macro Lambda Lists.
> >
> >a) would you agree that (defmacro foo bar bar) is not allowed?
> > The Macro Lambda List is a list, so a single variable,
> > here BAR, is not allowed?
>
> Correct. The description of destructuring says that wherever a variable is
> allowed and a list would not be, you can replace it with a list and it will
> be destructured; it doesn't say you can go the other way and merge a list
> into a single variable.
>
> However, the logic of allowing the transformation in both directions makes
> a little sense, so it doesn't seem like an unreasonable extension. You can
> get the same effect with (defmacro foo (&rest bar) bar), but it might be
> easier for program-generating programs to deal with the simpler form.
Genera allows it, MCL not.
> >b) looking at the lambda-list production:
> >
> > ( . var ) would be valid?
> >
> > But it makes no sense, right?
>
> That's not valid list syntax at all, because of the answer to (c). So it
> never gets processed as a lambda-list.
>
> >c) what is ( . symbol) anyway? Is it something the reader
> > should be able to read?
>
> No. See section 2.4.1, where the syntax of lists is described. It says
> "If a token that is just a dot ... is read after some object ...". In the
> above case, the dot is not after an object, so it's not a consing dot. And
> section 2.3.3 says that a token consisting entirely of dots signals an
> error unless it's in the appropriate situation for a consing dot. So the
> above notation must signal an error.
The Lispm does signal an error. MCL not.
> If that syntax were allowed, then the obvious meaning for it should be
> equivalent to SYMBOL by itself. If CL didn't require an error to be
> signaled then I suppose an implementation could support it as an extension
> (it might fall out naturally from some algorithms for implementing the list
> reader macro).
Thanks,
Rainer
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/