Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > Macros? Unfortunately to my world, macros are those things > found in C, high-powered assemblers, and pre-VBA Office. As such, > they do anything but keep a language small, and one encounters > multiple implementations of similar functionality -- each > implementation the pride of one person, and abhorred by the person > who now must edit the code.
Comparing C macros to Lisp macros is like comparing a Sawzall to a scalpel. Regarding having enough rope to hang yourself, the same claim can be made about any language abstraction mechanism. E.g., classes are to data types as macros are to syntax. You can abuse classes and you can abuse macros. Both abuses will lead to abhorring by your collaborators. And either abstraction mechanism, when used properly, will result in more elegant, easier to read and maintain code. Both abstraction mechanisms also allow language feature exploration to occur outside of the privileged few who are allowed to commit changes into the code-base for the interpreter or compiler. I think that this is one of the things that Gerry Sussman might be getting at when he talks about how science works. (Or at least that's what I would be getting at if I were in his shoes.) In the Lisp community, for instance, there have been lots of language features that were implemented by people who were not part of the core language development clique, but that were later widely adopted. E.g., the Common Lisp OO system with mutimethods (CLOS), and the "loop" macro. These features didn't require any changes to the core language implementation, and so you can see that Lisp-style macros are also a huge modularity boon for language implementation. |>oug -- http://mail.python.org/mailman/listinfo/python-list
