Macros and destructuring and functions, oh my!

[George J. Carrette <GJC at MIT-MC>]

This comment is more of a bug note, but to tell you the truth
I have even found the destructuring provided by DEFMACRO on
the lispm and in maclisp to be poor in the "syntax-checking" and
error message features they provide to the user of a macro which
happened to be written using destructuring. 

Say I write (defmacro foo ( ( a b) C) ...), but you call it as
(foo X Y). In JONL's complr this would cause A and B to be bound to
random bad pointers (well I guess B would be the CAR of the PLIST of X),
the COMPLR does strange things when given such strange input!
even in the maclisp interpreter you would get a strange looking error.
On the lispm you get an error when taking the CAR of X, which is nice,
and you can use the error handler to find out that you are macro-expanding
(FOO X Y), but its still not as nice as a "Bad syntax to macro FOO,
the second argument was intended to match against: (A B)"

In maclisp especialy I think we need a destucturing mechanism which
has error checking which is context informative (in terms of error
messages).  In defmacros this is more important to me than the optimal
code in terms of least number of CAR's and CDR's and stack space used
which JONL's destructuring LET now provides. [However, that technology
of optimaly picking apart data is useful for other things.]

-gjc