[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Common Lisp "let"



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