[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DESTRUCTURING-BIND (Version 2)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Issue: DESTRUCTURING-BIND (Version 2)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 3 Feb 89 18:11 EST
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <890130100149.3.KMP@BOBOLINK.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.