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

[no subject]



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

    Date: 26 September 1980 12:17-EDT
    From: Daniel L. Weinreb <dlw at MIT-AI>
    Sender: dlw at CADR2 at MIT-AI
    To:   GJC
    cc:   BUG-LISP, BUG-LISPM, MACSYMA-I

        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.

Come come now.  "you seem to not understand the philosphical basis".
I know this is a sore spot, but such attacks!

The case in point happens to be the functions which do macsyma->lisp
translation, and in fact they do translation, and take input in
a syntactic manner just like DEFMACRO. O.K. It may be a crock that
one even needs to do macsyma->lisp translation, but thats another story.

-gjc