--On Sunday, January 12, 2003 02:50:59 +0100 Samuele Pedroni <pedronis@bluewin.ch> wrote:
Has anyone thought about features that Python does not have that should be in Minimal? My first candidate would be (ducks) macros,
as a final user visible feature, I hope not. As an implementation then invisible tool maybe/why not.
That's more or less how macros are used most places that have them. For instance, only three files in the non-compiled-in (i.e. non-core) parts of xemacs have any macros defined in them (and two of those are compatibility things for other versions of emacs, never even defined if running on an xemacs), but most packages use at least some of the macros defined in the core. From the outside, those macros just look like parts of the exported language. The one remaining user of defmacro is advice.el, which defines the generic before/after/around advice mechanism, which could also be regarded as part of the core, and probably will be in some future version.
since that could drastically simplify constructing core Python features. I have some thoughts on pythonic ways to do that which I need to write up.
there is really no pythonic way to do macros. You can check this python-dev thread
http://aspn.activestate.com/ASPN/Mail/Message/1076771
My personal opinion is that entering the realm of language (re)design vs. simply implementation is a risky move...
I have several things in mind for macros: 1) pyrex-like cdef as a means to implement interfaces to C modules, but instead of outputting C and compiling, having psyco's code generator build it. 2) More efficient struct and sstruct like modules to tie in with 1) 3) Means to (as another poster has suggested) build dictionaries, sets and list comprehensions including their syntax. 4) Advice, like the elisp version I mentioned above. This is probably the only one of these where I'd like to see a change in the language officially exported, and I'm not that fussed about it, frankly. 5) Possibly a hook to do templating language things without preprocessing and without horrible performance problems. In lisp dialects macros are mostly ways to build core syntax, and ways for the gurus to do scary things without killing performance, that usually result (so far as most users are concerned) in a special-purpose sublanguage. I think the latter already applies to python metaclasses, and would apply to macros too. My suggestion is really just a hook in a place where it doesn't already exist, on the before side of class definition where metaclasses come after. In the context of Minimal Python, macros provide a clean and consistent mechanism to reduce the C code by providing the hooks to build parts of the language in python. These don't already exist, and I'd prefer to see something generic than random hackery. Presuming that the parser will move to python, it would be a fairly natural use of python's dynamicism to allow define-time additions to the parser. Andrew