[no subject]

[Daniel L. Weinreb <dlw at MIT-AI>]

cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC

    Date: 26 September 1980 09:40-EDT
    From: George J. Carrette <GJC at MIT-MC>
    To: JPG at MIT-MC
    cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC

    I think its a bit of a crock that destructuring is supported in Defmacro
    but not in Defun, for the following reason: many times one writes
    auxiliary functions which are also syntactic in the way they take
    their arguments. If somebody writes (defun foo ((a b)) ...)
    it doesn't mean they are violating data-abstractions. Of course,
    they MIGHT be violating data abstractions.
    
    So, when are we going to see a more general destructuring and binding
    mechanism, one that can handle more than just lists?
    
    -gjc


It is not a crock.  It is intentional. You seem to not understand the
philosophical basis of what is going on here.  The thing after the macro
name in a "defmacro" form is NOT an argument list.  The thing after the
function name in a "defun" form IS an argument list.  The two are
totally different and have nothing to do with each other.  Functions
take arguments; macros don't take arguments.  Functions compute; macros
translate.  A translator's job usually is to take the structure apart
and put it back together with some new stuff in a different way.  A
computer's job is to take several objects, compute upon them, and
produce side effects and a result.  If the computation done by the
computer just happens to include taking CARs and CDRs of the objects it
is passed, that just happens to be what one function is doing, and has
nothing to do with functions in general.  That is why LispM defuns do
not have "destructuring lambda lists", and why I belive they should not.