Douglas Alan wrote: > "Terry Reedy" <[EMAIL PROTECTED]> writes: > >> "Douglas Alan" <[EMAIL PROTECTED]> wrote in message > >> | > 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. > >> Anyone can write modules, experimental or otherwise, without touching the >> code base for any particular implementation. > >> For those whose know one of the implementation languages, source code >> control systems allow one to do experiments on branches without 'sullying' >> the trunk or impeding the development thereof. > > When I said "without having to sully the code base", I meant that one > can implement a language feature for the target language as a loadable > module written entirely within the language itself, and without having > to understand anything particularly deep or specific about the language > implementation details. > > I.e., I could write a new object system for Lisp faster than I could > even begin to fathom the internal of CPython. Not only that, I have > absolutely no desire to spend my valuable free time writing C code. > I'd much rather be hacking in Python, thank you very much. >
CPython's class system is independent of the interpreter proper. That is how two class systems, classic and new-style, can exist in the same language. Both class types implement hooks into attribute lookup. By providing __getattr__/__getattribute__, __setattr__, and __delattr__ methods one can effectively alter object behavior, such as method resolution. And metaclasses change the nature of class statements. Novel objects systems, such as prototypes, are possible. So the Python language provides more of a framework for handling objects rather than defining an actual object model. Python is the syntax; objects define the behavior. Finally, with the advent of Python 2.2, built-in types like int and list became far more class like. Subclassing became possible. The object types were reworking at the interpreter level. No amount of macro wizardry could have done it. >> One of the goals of the PyPy project was to allow people to experiment with >> syntax extensions in Python itself. (But I don't know how easy that is >> yet.) > > PyPy sounds like a very interesting project indeed! > PyPy uses aspects without needing macros. >> But I think that overall the problem of designing new syntax is more >> in the design than the implementation. Anything new has to be >> usable, readable, not clash too much with existing style, not >> introduce ambiguities, and not move the extended language outside >> the LL(1) [I believe that is right] subset of CFLs. > > People (myself included) haven't had much trouble implementing nice > and useful macro packages for Lisp. Admittedly, it's a harder problem > for a language that doesn't have a Lisp-like syntax. I believe that > Dylan has macros without having a Lisp-like syntax, but Dylan is > really a dialect of Lisp, only with a more traditional Algol-like > syntax veneered onto it. My guess is that a macro developer for Dylan > would have to be familiar with an underlying hidden intermediate Lisp > syntax. (Though I'm just really just spouting that guess out of my > butt.) > Dylan macros do not use an "underlying hidden intermediate Lisp syntax". They are language-based, doing pattern matching on Dylan language elements ( http://www.opendylan.org/books/dpg/db_329.html ). > A few years back, I designed a somewhat Python-like language with a > macro facility for a class on dynamic languages and their > implementations. I didn't implement it, however, and I doubt that > I'll have time to get around to it in this lifetime. > It's easy to say Python would benefit from macros. Macros have solved problems in Common Lisp and Scheme and so it is assumed they can do the same for Python. But no concrete suggestions are made in this thread. No specific macro mechanism is put forward for Python. No example is given on how to implement some Python feature with it. No point has been identified in the Python compiler chain for macro expansion. When this thread turned to the topic of macros I did an Internet search for information on macros relevant to Python. Dylan's macros look promising. The Python-inspired language Converge has macros ( http://convergepl.org/ ). Michael Hudson's Bytecodehacks package supports limited Python macros ( http://bytecodehacks.sourceforge.net/bch-docs/bch/module-bytecodehacks.macro.html ). There is also the __macro__ package, which I still have on my computer, but I cannot find its home page. The __macro__ package simply allows text substitution of source code at module import time. The bytecodehack.macro module lets one define what amounts to inlined functions. IMO neither package represents a productive macro system. And I could find no other attempts to take Python macros beyond wishful thinking. So until some solid proposal for Python macros is put on the table any discussion of their merits is unproductive. I can suggest though that procedural macros are a natural starting point given the runtime nature of class and function creation. -- Lenard Lindstrom <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
