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 ?

Spiros Bousbouras <spibou@gmail.com> wrote:
> 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 ?
>

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

Spiros Bousbouras <spibou@gmail.com> writes:

> 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 ?

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.

On 2022-04-10, Spiros Bousbouras <spibou@gmail.com> wrote:
> 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 ?

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

Kaz Kylheku <480-992-1380@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

On Tuesday, April 12, 2022 at 1:00:30 AM UTC-7, Zyni Moë wrote:
> 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?

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.