Re: Issue IGNORE-VARIABLE, v1

[masinter.pa@Xerox.COM]

I didn't check the references when this was first proposed, but presumably
pp 55-56 and 59-65 of CLtL have some indication that duplicates are not
allowed. This issue was "withdrawn", i.e., we didn't propose it.

     ----- Begin Forwarded Messages -----

Date: Mon, 7 Mar 88 15:06 EST
 From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU

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.



     ----- Next Message -----

 From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:28:54 gmt
To: CL-Cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Cc: KMP@scrc-stony-brook.arpa

Current practice:
  Both PopLog Common Lisp and KCL allow variables to appear more
  than once in a lambda-list.  In the three suggested test cases,
  they both have the later binding current in the body of the form
  and so return the values 2, 1, and 1 respectively.

  In addition, both allow variables in other cases, specifically:

  KCL:
    ((lambda (a a) a) 1 2) => 2
 
  PopLog:
    ((lambda (a a) a) 1 2) => 1



     ----- Next Message -----

Date: Fri, 11 Mar 88 13:43 EST
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I oppose LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE; I think
Common Lisp should continue to forbid binding the same variable more
than once in the same binding form.  I have two reasons:

1. This is an unnecessary complication of the language rules.  Allowing
duplicated variable names doesn't make it possible to write programs
that you couldn't write before, it just allows the programs to be
written in a more obscure way.

2. This would result in an unnecessary complication of the scoping rules
for DECLARE.  Common Lisp would have to define what happens when a
DECLARE of a variable is attached to a form that binds more than one
variable with the declared name.



     ----- End Forwarded Messages -----