[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some easy ones (?)
- To: NGALL@G.BBN.COM
- Subject: Re: Some easy ones (?)
- From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
- Date: Thu 24 Jul 86 09:56:39-PDT
- Cc: FREEMAN@SUMEX-AIM.Stanford.EDU, Fahlman@C.CS.CMU.EDU, common-lisp@Sail.Stanford.EDU
- In-reply-to: <[G.BBN.COM]23-Jul-86 21:39:54.NGALL>
Nick (NGALL@G.BBN.COM) replied:
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Nick (NGALL@G.BBN.COM) replied to Fahlman:
Proposal #9: Variable Name Conflicts
Specify that it is an error for two parameters (including
supplied-p and &aux parameters) in the same lambda-list to
have the same (EQL) name.
Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET,
MV-BIND, and PROG.
I don't know about DO*, but LET* should be able to shadow previous
names. The restriction seems reasonable for the others mentioned.
Why should LET* be able to shadow previous names when LAMBDA expressions
(I'm still ignoring do*. Somebody must have an opinion.)
Let* is syntax for multiple nested lambda expressions with arguments.
The names bound by all of the other forms mentioned could conceivably
be bound by a single lambda expression (ignoring the separate function
name space). That's not true of let* (without renaming things).
Ignoring declarations for the nonce.
(let* (<b1> <b2> . <bn>)
is the same as
(let* (<b2> . <bn>)
If let* doesn't allow duplicate names, then we'll end up writing
nested let* expressions (which is senseless, let* was invented to
avoid nested let expressions) or using setq more than necessary.
Why do you object to duplicate names in let*?