Re: RE: Common Lisp "let"

[Paul Graham <address@hidden>]

Actually I think current Lisp dialects use excessive parens here.
In Arc we use let for the single variable case (since that turns
out to be the most common) and have no parens except for those
around the let:

(let x 10 ...)

For the multi-variable case we use with, and even there we
only need one pair of parens:

(with (x 10 y 3) ...)

Not only did I get used to this, I found it so annoying to have
to type the extra parens in CL that I wrote macros to do the same
thing in CL.

--pg

--Anton van Straaten wrote:
> > > It is obviously more verbose than either prefix
> > > or infix, but that may be a feature.  cf.
> > > "Lisp syntax considered insufficiently redundant"
> > > http://lists.canonical.org/pipermail/kragen-tol/2002-April/000705.html
> >
> > Regarding your point about the syntax being insufficiently redundant: I
> > agree with you that it was a mistake to allow "let" to accept the "var"
> > form as well as the "(var value)", for exactly the reason you say.
> >
> > However, in my opinion, this is just a mistake in the design of
> > "let" rather than being a serious systemic problem with Lisp-like
> > syntax.
> 
> Confirmation of that can be found in Scheme, since the given example,
> transliterated into Scheme:
> 
> 	(define (isletter char)
> 	  (let (dcchar (downcase char))
> 		...
> 
> ...would simply produce an error message, typically about a malformed "let".
> The correct Scheme version needs an extra pair of parentheses, which I
> suppose could be described as being more redundant:
> 
> 	(define (isletter char)
> 	  (let ((dcchar (downcase char)))
> 		...
> 
> ...since the extra parens eliminate the potential for this kind of ambiguity
> within the let.  So the necessary "redundancy" doesn't have to be
> particularly intrusive, at least in this case.
> 
> I think that given a grammar for Lisp, containing explicit definitions for
> constructs like "let", this ambiguity could have been detected by an
> automated tool, e.g. a parser generator.  This static check of the
> language's grammar could have prevented the error which Kragen encountered,
> so many years after the language feature was designed.  An interesting
> example of the benefits of static checks, even for the grammar of dynamic,
> macro-rewritable languages?  ;)
> 
> Anton
>