Destructuring Lambda Lists

26 views
Skip to first unread message

Spiros Bousbouras

unread,
Apr 10, 2022, 6:04:02 PMApr 10
to
3.4.5 Destructuring Lambda Lists :
A destructuring lambda list can contain all of the lambda list
keywords listed for macro lambda lists except for &environment
[...]
envvar::= [&environment var]

Is the appearance of envvar::= [&environment var] an error ?

Zyni Moë

unread,
Apr 10, 2022, 6:23:16 PMApr 10
to
Technically no: nothing in the other productions refers to it, so it can
not make any difference. In fact, yes: has clearly been left in when
editing macro lambda list.

--
the small snake

Lieven Marchand

unread,
Apr 11, 2022, 12:12:08 PMApr 11
to
Unless I'm missing something it's not used in any production rule so at
most some extraneous copy pasting.

--
Laat hulle almal sterf. Ek is tevrede om die wêreld te sien brand en die vallende
konings te spot. Ek en my aasdier sal loop op die as van die verwoeste aarde.

Kaz Kylheku

unread,
Apr 11, 2022, 4:39:56 PMApr 11
to
I think it has to be in the syntax so that implementations can diagnose
it as an error.

Remember that &whatever are ordinary symbols.

If the documentation only said this:

"A destructuring lambda list can contain all of the lambda list
keywords listed for macro lambda lists except for &environment"

and made no other mention of the parameter, then a possible
interpretation would be that: destructuring lambda lists do not support
&environment --- and therefore, in destructuring lambda lists,
&environment is just an ordinary symbol which is semantically a
parameter name.

According to this interpretation, implementations would not be able to
reject it, only emit a nuisance diagnostic like "warning: &environment
is an ordinary symbol in destructuring-bind", but then obligingly
proceed with the symbol as ordinary, in order to remain conforming.

The syntax makes it clear that destructuring lambda lists *have* an
envvar phrase structure in the *syntax*. The other requirement makes it
clear that *instances* of this phrase structure are not supported
for that kind of lambda list.

Just because something is in the syntax doesn't mean it may be used;
languages often allow more combinations in the syntax than is
semantically valid.

E.g. in C, "unsigned short double" is valid syntax; a constraint rule
rejects this combination of specifiers as invalid. Static type checks
are another source of examples of the concept.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Zyni Moë

unread,
Apr 12, 2022, 4:00:30 AMApr 12
to
Kaz Kylheku <480-99...@kylheku.com> wrote:

>
> I think it has to be in the syntax so that implementations can diagnose
> it as an error.
>

It is not present in syntax for ordinary lambda lists: does that mean it is
legal there: what should (lambda (&environment foo) ...) do?

--
the small snake

Tom Russ

unread,
Apr 12, 2022, 4:30:57 PMApr 12
to
FWIW SBCL signals an error for
((lambda (&environment foo) (print foo)) ...)

In any case, it would be an unwise name to choose for an ordinary variable.

Reply all
Reply to author
Forward
0 new messages