I get OK with my versions of clisp and cmucl and (as I'd have expected) an
error in sbcl.
Is returning OK an implementation bug (I can't immediately find it in the
Hyperspec)?
'as
Alexander Schmolck wrote:
> I get OK with my versions of clisp and cmucl and (as I'd have expected) an
> error in sbcl.
>
> Is returning OK an implementation bug (I can't immediately find it in the
> Hyperspec)?
I'm very tired, but I seem to recall that this comes from the
requirements related to ordinary lambda lists. See 3.4.1.3. According
to this, an empty lambda list can only match an argument list of zero
arguments. E.g. you can't call a function that takes no arguments and
pass it an argument. In the case of destructuring, no arguments means
empty list, which the object X isn't.
From: Kent M Pitman
Subject: Re: (destructuring-bind () 'X 'OK) => ?
Date:
Message-ID: <u7j2u41k3.fsf@nhplace.com>
Alexander Schmolck <··········@gmail.com> writes:
> I get OK with my versions of clisp and cmucl and (as I'd have expected) an
> error in sbcl.
>
> Is returning OK an implementation bug (I can't immediately find it in the
> Hyperspec)?
As far as I can tell from
http://www.lispworks.com/documentation/HyperSpec/Body/03_de.htm
and as far as I can recall from original design (not that that matters;
only the words of the spec have any real meaning now) the intent was
that destructuring-bind did error-checking and you had to use &optional
or &rest to achieve optionality.
This is different than multiple-value-bind such as
(multiple-value-bind () 'foo 'ok)
where value overrun and underrun is not flagged, and is different than
the sadly low-tech destructuring done in LOOP patterns such as
(loop for x below 1 for () in '(x) do (print 'ok))
where () means to match anything and bind nothing.
Alexander Schmolck <··········@gmail.com> writes:
> Is returning OK an implementation bug (I can't immediately find it
> in the Hyperspec)?
3.4.4 Macro Lambda Lists has this:
It is permissible for a macro form (or a subexpression of a macro
form) to be a dotted list only when (... &rest var) or (... . var)
is used to match it.
Also, in CMUCL:
(defmacro foo () :OK)
(foo . x) => :OK
--
Marcus Breiing
Marcus Breiing wrote:
> Alexander Schmolck <··········@gmail.com> writes:
>
> > Is returning OK an implementation bug (I can't immediately find it
> > in the Hyperspec)?
>
> 3.4.4 Macro Lambda Lists has this:
>
> It is permissible for a macro form (or a subexpression of a macro
> form) to be a dotted list only when (... &rest var) or (... . var)
> is used to match it.
But X is a atom, which is not considered a dotted list!
"Kaz Kylheku" <········@gmail.com> writes:
> > 3.4.4 Macro Lambda Lists has this:
> >
> > It is permissible for a macro form (or a subexpression of a macro
> > form) to be a dotted list only when (... &rest var) or (... . var)
> > is used to match it.
>
> But X is a atom, which is not considered a dotted list!
You're right -- that's indeed what the glossary says.
I must admit I've always considered arbitrary atoms to be a special
case of dotted lists, not the least reason being that just as I think
of LIST as the function that creates proper lists, I think of LIST* as
the function that creates dotted lists -- and LIST* certainly can
produce any "naked" non-nil atom.
Observing that the quoted passage from CLHS Section 3.4.4 speaks of
the (whole) macro form as being the dotted list, things at first
seemed to be somewhat salveageble, but as it also says that the (...
&rest var) (etc) must match "it", with "it" clearly referring to the
"dotted list", I'm not that confident anymore.
Maybe someone (Kent?) could shed some light on these two related
questions:
(a) Must a &REST-variable really not match 2 even though it may match
(1 . 2)? (Which also implies that subform pattern X is not equivalent
to (&rest X))
(b) [only if 'otherwise'] Is it the glossary entry for "dotted list"
that is in error, or the language in 3.4.4?
--
Marcus Breiing