[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LAMBDA-LIST-DUPLICATES (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 7 Mar 88 15:06 EST
References: 5.1.2 Variables (pp55-56)
5.2.2 Lambda-Expressions (pp59-65),
LET* (p111-112), PROG* (pp131-132)
Edit history: 07-Mar-88, Version 1 by Pitman
Related Issues: DECLARATION-SCOPE
Status: For Internal Discussion
CLtL forbids binding the same variable more than once in the same
binding form. This rule is claimed by some to be overly restrictive
because there are some well-defined situations in which it would be
useful to duplicate a variable name in the same binding list.
Allow variable names to be repeated in situations where bindings are
sequential and the binding construct is non-iterative (specifically,
in the &AUX part of a normal lambda list, in the bindings of LET*, and
in the bindings of PROG*).
((LAMBDA (B &AUX (B (+ B 1)) (B (+ B 1))) B) 0) => 2
(LET* ((B 0) (B (+ B 1))) B) => 1
(PROG* ((B 0) (B (+ B 1))) (RETURN B)) => 1
Because these bindings are inherently sequential and non-iterative, there
would no ambiguity about the intended scope bindings, and it is sometimes
useful to repeat the name of a binding when doing various kinds of
encapsulations or successive refinements to the same value.
The intent of duplicated bindings in "parallel binding" constructs like
LET or iterative constructs like DO* is less easy to predict, so it is
not proposed that the current rule be relaxed for such constructs.
The Symbolics implementation currently checks for this case and
signals an error.
Cost to Implementors:
Converting would be relatively easy, but not completely trivial.
There is some interaction with declaration processing which becomes
involved, too (see issue DECLARATION-SCOPE).
Cost to Users:
None. This is an upward-compatible change.
Cost of Non-Adoption:
Some useful expressional style would be lost.
A useful expressional style would be made available.
The rule for variable duplication would be more syntactically complex
but pragmatically simpler.
A request for a discussion of this issue came from the Japanese community.
Pitman drafted this formal proposal and supports