"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. > 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! > 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.) 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. |>oug -- http://mail.python.org/mailman/listinfo/python-list