Neil Cerutti <[EMAIL PROTECTED]> writes: >>> But why is the ability to abstract syntax good?
>> It allows the community to develop language features in a >> modular way without having to sully the code base for the >> language itself. > That's not an advantage exclusive to macros, though. No, but macros are often are necessary to be able to implement such features in (1) an efficient-enough manner, and (2) in a manner that is syntactically palatable. E.g., PEAK for Python implements multiple predicate-based dispatch, but you have to define the predicates as Python code within strings. That's not very pretty. And probably not very fast either. Though Python, in general, is not very fast, so perhaps that doesn't matter too much for Python. > Some time last week I found myself writing the following thing in > Python: > [...] > I deleted it right after I tried to use it the first time. Using it > is more cumbersome than simply repeating myself, due to syntax > limitations of Python. See what I mean! > And other, more bizarre syntax extensions have been perpetrated. > mx.TextTools uses Python tuples to write a completely different > programming language. Sounds like "the Loop macro" for Lisp, which implements a mini sort of Cobol-like language just for coding gnarly loops within Lisp. It turns out that when restricted to just coding gnarly loops, this is a much better idea than it sounds. Yes, you can do this sort of thing, sort of, without macros, but, as we discussed above, the result is often ugly and slow. >> A prime example of this is how CLOS, the Common Lisp Object >> System was implemented completely as a loadable library (with >> the help of many macros) into Common Lisp, which was not an OO >> language prior to the adoption of CLOS. > Is there a second example? ;) Why yes, now that you mention it: the Loop macro. Also, in many implementations of Lisp, much of the core language is actually implemented using macros against an even smaller core. Keeping this inside core as small as possible helps make the implementation easier to construct, maintain, and optimize. Also, way back when, when I used to code in Maclisp, I implemented my own object system and exception handling system in macros, as Maclisp had neither of these off the shelf. The object system took me a couple of weeks to do, and the exception handing system a couple of days. They worked well, looked good, and ran fast. > Seriously, maybe Python looks like 'blub' (thanks, Paul Graham), to > the skilled Lisp user, but it makes a lot of other languages look > like 'blub', too, including, sometimes, Lisp: Lisp has to 'blub' > generators. Actually, Scheme has first class continuations, and with continuations and macros you could easily implement generators, and I'm sure someone has. Whether such a library has been widely adopted for Scheme, though, I have no idea. You're probably right about Common Lisp, which is probably missing generators due to efficiency concerns. Lisp Machines had "stack groups", which were basically the same thing as generators, but making a call to a stack group was 100 times slower than a normal function call. This meant that people generally didn't use them even when it would make their code more elegant, due to the huge performance cost. Now, since Python is like 100 times slower than Common Lisp anyway, you don't notice this performance issue with Python's generators. They just happen to be only as slow as the rest of Python. |>oug "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." -- Eric Raymond -- http://mail.python.org/mailman/listinfo/python-list
