[pypy-dev] Questions about the C core
andrew at indranet.co.nz
Sun Jan 12 11:59:51 CET 2003
--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.
More information about the Pypy-dev