[pypy-dev] Questions about the C core

[Andrew McGregor]

--On Sunday, January 12, 2003 02:50:59 +0100 Samuele Pedroni 
<pedronis at 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