Re: Destructuring LET

[Kent M. Pitman <KMP at MIT-MC>]

    Date: 3 February 1981 03:04-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    Re:   Destructuring syntax

	From: JONL

        In the LISP RECENT note (now in the LISP NEWS file) dated "Jan 27,1979"
        there was presented a very succinct bnf syntax for "lambda-lists", 
        which would take care of LET, DEFUN, DO, PROG etc... This syntax is
	fully-upward compatible, and entirely unabmiguous (as the bnf shows);  

Personally, I think the proposed bnf was terrible. I think it was a terrible
idea to have introduced &keywords into Lisp in the first place. There were
alternative ways of specifying things that would have been much more elegant.
But that change is in a lot of code now and there's no real way to change it.

I was highly disappointed in GLS for the support he lent to that discussion 
(2-Oct-80: Destructuring Syntax). His suggestions are usually more sound.
Describing lisp syntax in terms of bnf is adding clutter to the language
definition which has no reason to be there.

	The fact that many ordinary users are rudely suprised when they
	find it is unavailable on the LISPM shows that it must be a
	"natural" extension too.

    This is ridiculous.  All this shows is that people are using it in their
    code.  My interpretation is simply that this "destructuring lambda" is
    an easy misconception for people to have.  Just because lots of people
    think something does not make it right.  The number of dialects that
    support it and the number of users who, having seen the announcement of
    the feature, started using it, does not affect my opinion.

Oh, it's fair to not worry about what people are using in their code? Then
perhaps I should push the issue of &keywords again and ask people to change
them. A number of people I have talked to agree they were a mistake, but 
feel they are too dug in to remove. Is there a double standard here?

Maclisp programmers use destructuring LET extensively. The failure of the Lisp
Machine to provide this feature deserves strong justification, since it means
that every time we try to transport programs to the Lisp Machine, we have to
either clobber the system LET, put the code on a separate package, or rewrite
a whole pile of code. None of these alternatives are very attractive. Since 
you are not currently attaching any meaning to the syntax used by destructuring
LET, you are in the best position to go for compatibility. I am not saying
you should do so for the sake of compatibility, I am saying you should
consider doing so for compatibility.

Making code as compatible as possible is of large value to a lot of people.
We really need to address that issue.

At the very least, LispM lisp should provide SOME primitive with the exact
semantics of Maclisp LET in the default system. It should preferrably be
about 3 characters long so that major reformatting of files isn't needed. 
I disagree that anything more than LET and LET* need to do destructuring.
Generalizing to make DO, PROG, etc. do the same thing is silly. I would, I
suppose, be satisfied with DLET and DLET* which could be macros. If you decided
to do this, then I would advocate RMS' suggestion not be adopted into the
syntax of LET, since LispM->Maclisp compatibility would be destroyed by such
an action in the same way as Maclisp->LispM compatibility is currently mucked 
up.

-kmp