Issue: DESTRUCTURING-BIND (Version 2)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 27 Jan 89 21:01 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I support version 2 of this.  I have a couple of minor comments:

    DESTRUCTURING-BIND should not allow &WHOLE any more than it should allow
    &ENVIRONMENT.  Those two features are specific to macroexpanders.

Sigh. EB sent something which touched on this same issue. I guess you're
right, but I think before we disallow them, we should probably make it
clear that &WHOLE and &ENVIRONMENT only belong at toplevel of a DEFMACRO
lambda list and not within. That would make the implementation-strategy
for DEFMACRO more apparent. I made a separate issue,
DEFMACRO-LAMBDA-LIST, to discuss this.

Actually, it seems to me that the same case could be made for &BODY. It
has no purpose in DESTRUCTURING-BIND since an explicit call to
DESTRUCTURING-BIND will never have to affect the way something pretty
prints. Nevertheless, since it is useful to have &BODY appear at recursive
levels of DEFMACRO binding forms, I think it should be permitted here.
Still, we should be up front about our motivations here.

    Both LOOP and DESTRUCTURING-BIND allow NIL in place of a variable
    name as a way of ignoring a portion of the destructured tree, in
    Symbolics current practice.  I think that's a good idea and should
    go in the standard. It's only an abbreviation for a dummy variable
    and a DECLARE IGNORE, but the whole destructuring feature is nothing
    but an abbreviation anyway.

This is ok with me. Does anyone object? If I hear no objection, this
change will be in the next version. Especially in error-checking versions
where you might otherwise appear to be matching an empty list by the
normal destructuring rules (signalling an error in some implementations)
this might be important.

Of course, there are other places where such a convention would be
useful, too. LAMBDA, MULTIPLE-VALUE-BIND and MULTIPLE-VALUE-SETQ come
immediately to mind. But I guess it's really too late to consider
ammending those. Oh well...