Issue: LAMBDA-LIST-DUPLICATES (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:          LAMBDA-LIST-DUPLICATES
References:     5.1.2 Variables (pp55-56)
	        5.2.2 Lambda-Expressions (pp59-65),
	        LET* (p111-112), PROG* (pp131-132)
Category:       ADDITION
Edit history:   07-Mar-88, Version 1 by Pitman
Related Issues: DECLARATION-SCOPE
Status:	        For Internal Discussion

Problem Description:

  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.

Proposal (LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE):

  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*).

Test Case:

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

Rationale:

  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.

Current Practice:

  The Symbolics implementation currently checks for this case and
  signals an error.

  [Others?]

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.

Benefits:

  A useful expressional style would be made available.

Aesthetics:

  The rule for variable duplication would be more syntactically complex
  but pragmatically simpler.

Discussion:

  A request for a discussion of this issue came from the Japanese community.
  Pitman drafted this formal proposal and supports
  LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE.