Issue: DESTRUCTURING-BIND (Version 2)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 30 Jan 89 10:01 EST
    From: 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.

I committed an error here.  &ENVIRONMENT is specific to macroexpanders,
but &WHOLE should be allowed in DESTRUCTURING-BIND just as it is allowed
other than at top level in DEFMACRO.  It's just that &WHOLE at top level
in DEFMACRO has a slightly special meaning.

    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.

I think it's more consistent to allow &BODY.

	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.

Note that whichever way we decide, DESTRUCTURING-BIND and DEFMACRO should
be consistent about allowing NIL to mean ignore.

    This is ok with me. Does anyone object? 

The main difficulty is that NIL in the cdr position has to be treated as
a special case, it can't be the same as an ignored variable in the cdr
position when DESTRUCTURING-BIND (as DEFMACRO does) regards mismatch
of length of a non-dotted list as an error.

X3J13 LOOP, as documented in 89-004, has this feature.  However, it is
inconsistent with DEFMACRO and (I think) DESTRUCTURING-BIND, because
LOOP destructuring does not consider list length mismatch an error.

					    If I hear no objection, this
    change will be in the next version.

Upon reflection, I'd like to withdraw the suggestion about NIL.  I don't
think it should be put into the standard at this time.

In fact the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced.  For some reason I was hesitant to suggest that; I think
I was being stupid.