[pypy-dev] Questions about the C core

[Andrew McGregor]

--On Saturday, January 11, 2003 21:03:55 -0800 David Ascher 
<DavidA at ActiveState.com> wrote:

> On the topic of macros et al:

...

> On the other hand, I'm going to lose interest in this project pretty fast
> if it turns into an _unsubstantiated_ argument about language design.  If
> a new language construct is proposed as a fairly direct and
> well-supported way to get the implementation done better, faster,
> cheaper, then by all means.

Which is why I suggested it.  I'm no expert on language design, but I can 
see that a standardised way to extend a language that starts out less than 
complete (as a Python core with major chunks removed will) is better than 
an ad-hoc mess.

Someone else suggested a sufficiently extensible parser, if I follow their 
intent, and I agree entirely.  In a sense, a macro system is just one 
possible interface to such an extensible parser.

Another suggestion was to allow an in-python way to interface with c system 
calls and library functions.  Scoped macros implementing a python 
derivative similar to pyrex have potential here, in the same way pyrex does 
for extending CPython.

In lisp, I always felt macros were best provided by the language designer 
or library designers, as part of the language or library.  Applications 
that made use of custom macros were generally hard to read, but if what 
they were doing was compiler-like (my case was symbolic math) usually made 
sense once understood.  I suspect the same would be true of python.

In other words, I think a macro system is a good way to get syntactical 
extensibility so that Minimal Python can acheive it's goals.  I think users 
should be discouraged from writing them, because of the potential 
nightmares unusual macros cause, but certain standard packages could 
provide some macros at little cost to the pythonicality of the results.  I 
think it would be pretty cool if 'from pyrex import *' led to following 
code having pyrex semantics; this would, I think, make it easier to get 
Minimal Python completed.

I also think that if metaclasses can be pythonic, there's a pythonic way to 
do macros too, but if consensus is against that, then let them simply be an 
implementation detail of Minimal Python.

Andrew