Section 6.1.1.7 of the ANSI CL spec states that:
"An error of type program-error is signaled (at
macro expansion time) if the same variable is
bound twice in any variable-binding clause of a
single loop expression. Such variables include
local variables, iteration control variables,
and variables found by destructuring."
I interpreted this as meaning that a loop expression
cannot bind the same variable twice, even if those
bindings are in different clauses (however, bindings
in forms within clauses don't count.)
A more restrictive reading would be that repeated
bindings of the same variable in a single clause
(either by destructuring or by subclauses linked with
the 'and' loop keyword) are illegal, but that it is
legal to bind the same variable in different clauses
For example, (loop with a = 1 with a = 2 ...) would be
legal, but (loop with a = 1 and a = 2 ...) would not
be.
What was the intent here?
Paul
Paul Dietz <············@motorola.com> writes:
> I interpreted [Section 6.1.1.7] as meaning that a
> loop expression cannot bind the same variable twice,
> even if [...] A more restrictive reading would be
> [...]
> For example, (loop with a = 1 with a = 2 ...) would be
> legal, but (loop with a = 1 and a = 2 ...) would not
> be.
>
> What was the intent here?
Just because something shows up in a separated LOOP clause in the
surface form doesn't mean it does in the expansion. In general, since
you don't know what the macro will expand into in terms of lower level
code, and since there are substantial (some might say "excessive")
restrictions on repeated variables in other more primitive binding
forms, I'd take a pretty conservative reading and assume that any
duplicated bindings at all are not a good idea for programmers to try;
though if you were an implementation, I'd tell you to assume that
programmers aren't gonna all notice such a restriction and it's worth
trying to make as many cases work as possible (that is, support a
liberal reading).
This is just my personal feeling though, not any official position.
I don't speak for the committee.
From: Paul F. Dietz
Subject: Re: ANSI CL question about LOOP
Date:
Message-ID: <3DE2F9E2.5010606@dls.net>
Kent M Pitman wrote:
> Just because something shows up in a separated LOOP clause in the
> surface form doesn't mean it does in the expansion. In general, since
> you don't know what the macro will expand into in terms of lower level
> code, and since there are substantial (some might say "excessive")
> restrictions on repeated variables in other more primitive binding
> forms, I'd take a pretty conservative reading and assume that any
> duplicated bindings at all are not a good idea for programmers to try;
> though if you were an implementation, I'd tell you to assume that
> programmers aren't gonna all notice such a restriction and it's worth
> trying to make as many cases work as possible (that is, support a
> liberal reading).
>
> This is just my personal feeling though, not any official position.
> I don't speak for the committee.
The spec is saying that a program-error has to be signalled in some
situations; what was the intent of this error signalling? If it was
to force the programmer to be not do dubious things, that suggests
the system should signal this error in as many cases as possible,
not restrict the signalling to a conservative subset of cases.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> The spec is saying that a program-error has to be signalled in some
> situations; what was the intent of this error signalling? If it was
> to force the programmer to be not do dubious things, that suggests
> the system should signal this error in as many cases as possible,
> not restrict the signalling to a conservative subset of cases.
"Portability" is "directional". That is, there are two possible stances
an implementation can take: (a) support "outward portability" [signal lots
of errors locally on theory it will only be harder to track the bugs down
in other environments you're less familiar with], or (b) support "inward
portability" [signal few errors on assumption that apparent errors are
really extensions that have meaning elsewhere; try to assign them meaning
locally for compatibility].