[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


re: [use of NIL as an implicitly ignored variable, in binding constructs]
    Of course, there are other places where such a convention would be
    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) ...)
    (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 --