sbcl and acl both allow d-b to bind a bare symbol, but
they have different expansions, and the hyperspec seems
to suggest that only lists are allowed. Is there any formal
or informal policy that implementers usually follow in
extending the spec, and should either of these be preferred
over either the HS or each other? The main differences
are that sbcl declares the value as a list, and neither one
signals an error. The hyperspec explicitly defines the
lambda list as being wrapped in parens.
acl:
CL-USER(1): (macroexpand-1 '(destructuring-bind x 1 x))
(LET* () (LET* ((#:G6 1) (X #:G6)) X))
sbcl:
CL-USER> (macroexpand-1 '(destructuring-bind x 1 x))
(LET ((#:WHOLE2137 1))
(DECLARE (TYPE LIST #:WHOLE2137))
(LET* ()
(LET* ((X #:WHOLE2137))
X)))
hyperspec:
http://www.lispworks.com/documentation/HyperSpec/Body/m_destru.htm#destructuring-bind
8.3. Destructuring
destructuring-bind lambda-list expression declaration* form*
The lambda-list supports destructuring as described in Section 3.4.5
(Destructuring Lambda Lists).
http://www.lispworks.com/documentation/HyperSpec/Body/03_de.htm
3.4.5 Destructuring Lambda Lists
lambda-list::= (wholevar reqvars optvars restvar keyvars auxvars) |
(wholevar reqvars optvars . var)
--Dan
------------------------------------------------
Dan Bensen http://www.prairienet.org/~dsb/
cl-match: expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
danb <·········@gmail.com> writes:
> sbcl and acl both allow d-b to bind a bare symbol, but
> they have different expansions, and the hyperspec seems
> to suggest that only lists are allowed. Is there any formal
> or informal policy that implementers usually follow in
> extending the spec, and should either of these be preferred
> over either the HS or each other? The main differences
> are that sbcl declares the value as a list, and neither one
> signals an error. The hyperspec explicitly defines the
> lambda list as being wrapped in parens.
Well, that is clearly implementation dependant behavior.
I don't know any policy, be it formal or informal, for implementers to
follow to extend the language. I think we may be thankfull for that,
it allows implementers to explore new ideas in total freedom.
On the other hand, they can always write some CDR.
http://cdr.eurolisp.org/
Well, actually there is one policy: let the customers vote with his
wallet on what solution is best. If you prefer acl's behavior, pay
its license and use it. If you prefer sbcl's pay its license and use
it.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> its license and use it. If you prefer sbcl's pay its license and use
> it.
... which is reasonably cheap! (And of course you always have the
option of pestering the developers for / writing your own
implementation of the version you'd prefer...)
Rupert
On May 18, 10:59 pm, danb <·········@gmail.com> wrote:
> sbcl and acl both allow d-b to bind a bare symbol, but
> they have different expansions, and the hyperspec seems
> to suggest that only lists are allowed.
By my reading of the spec a symbol is a legit destructuring lambda
list. As you quoted, the grammar ends with:
> lambda-list::= (wholevar reqvars optvars restvar keyvars auxvars) |
> (wholevar reqvars optvars . var)
>
The case of X as a lambda list is just the degenerate case of the
second form. If wholevar, reqvars and optvars are omitted (and they
are all three optional) you end out with a bare symbol playing the
role that var does in that dotted list.
But setting aside language lawyering for a moment, the reason there
are two options in that bit of the grammar is because destructuring-
bind was supposed to be supporting two types of lambda-lists. The
first is the normal CL style. The second one is a style that shows up
historically in Lisp, where cons structure is used to express the same
thing that &rest does. For these sorts of lambda-lists the only way
to express the equivalent of a single &rest argument is to give a
symbol as the lambda list.
> sbcl:
> CL-USER> (macroexpand-1 '(destructuring-bind x 1 x))
> (LET ((#:WHOLE2137 1))
> (DECLARE (TYPE LIST #:WHOLE2137))
> (LET* ()
> (LET* ((X #:WHOLE2137))
> X)))
The random, oldish SBCL I just tried this on didn't include the type
declaration. I think that might not be a legitimate assertion either,
because I would expect
(destructuring-bind x 1 x)
to work as well as
(destructuring-bind (x y . z) '(1 2 . 3) z)
I guess I should check this out on a newer sbcl.
From: Richard M Kreuter
Subject: Re: destructuring-bind x ...
Date:
Message-ID: <87fxsdm69z.fsf@progn.net>
danb <·········@gmail.com> writes:
> sbcl and acl both allow d-b to bind a bare symbol, but
> they have different expansions, and the hyperspec seems
> to suggest that only lists are allowed. Is there any formal
> or informal policy that implementers usually follow in
> extending the spec, and should either of these be preferred
> over either the HS or each other?
Unless the implementor documented things otherwise, I would expect the
DESTRUCTURING-BIND behavior you've discovered to be a bug, rather than
an extension.
--
RmK