[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DESTRUCTURING-BIND (Version 2)
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: DESTRUCTURING-BIND (Version 2)
- From: Jon L White <jonl@lucid.com>
- Date: Tue, 31 Jan 89 02:29:58 PST
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Kent M Pitman's message of Mon, 30 Jan 89 10:01 EST <890130100149.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
re: [use of NIL as an implicitly ignored variable, in binding constructs]
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...
You might not remember that VAX/NIL had regular destructuring as a standard
feature of LET and DEFUN, along with the ignore-NIL hack. The one place
that it didn't easily generalize was for SETQ -- thus VAX/NIL had a
special-form/macro called DESETQ, as a destructuring version of SETQ.
As I remember it, some folks objected to the destructuring capability
for LET based on what they thought ought to be "primitive"; and others
objected to it in DEFUN for similar reasons. Of course, from an
implementational point of view, neither LET nor DEFUN is typically
primitive; they are simply the portable interface to a useful construct.
But the final killer for these extensions were what you term the
"religious wars" regarding how to specify destructuring over a list:
(destructuring-bind (a b c) (produce-a-list) ...)
or
(destructuring-bind `(,a ,b ,c) (produce-a-list) ...)
VAX/NIL actually used an extended form like:
(destructuring-bind #(a b c) (produce-a-vector) ...)
and *almost* had another extension like:
(destructuring-bind #S(FOO a b c) (produce-a-struct-FOO) ...)
Neither extension was extensible in the more general sense, but they
were certainly useful in writing a peephole optimizer for the output
a NIL compiler.
Incidentally, the place where LOOP and your recent proposal might
"share" is if there were a destructuring version of SETQ. It's
unlikely, however, that as many implementations provide the
equivalent of DESETQ as provide DESTRUCTURING-BIND. Again, I
might mention that I feel there is a low-level primitive that
would facilitate writing all these "destructuring" forms --
for LOOP, for DESTRUCTURING-BIND, for DESETQ, etc -- but it may
not be worth it to try to "kernelize" this idea.
-- JonL --