[pypy-dev] Questions about the C core

[Christian Tismer]

David Ascher wrote:
> On the topic of macros et al:

No macros!

> I think that delivering minimal python will be quite hard.  If the 
> mandate is to create a new implementation of Python, then I think that 
> the syntax of current Python should be seen as a "minimal" requirement 
> from a syntactic POV.  New syntactic elements can clearly be defined as 
> well, although naturally care should be taken to ensure that existing 
> code still works. (so making 'spam' a reserved word probably wouldn't 
> work).

The last thing Minimal Python is targetted to is changing
the language! We might decide to just implement a subset
of the language, but we should really avoid to change
anything, unless we have to.
Changing the internals so radically as we are planning to
do creates a lot of problems. I don't want to add language
changes as yet another problem.

With the new flexibility, which a re-implementation of
Python in Python hopefully rpovides, it will be much easier
to experiment with new language features than today.
But before doing that, if at all, we need to get the
basic stuff running.

Especially for macros, I don't see any necessity right
now. If we need to implement a template system for
parameterizing often repeated python code, we have
the simple approach to generate Python source from
formatted template strings. If that is used extensively
and turns out to be insufficient, we can think of
something better.
But nothing should be added before trying it without.

> 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.

I don't see any reason to add anything now.
The purpose of MiniPy is to remove as much as
possible, especially from the C code. Things
can then be re-implemented in Python, they
can be thought over and get a different design
to try out.
I also see no problem with the Python language
as it is now. Most of it is available as Python
code in the compiler module. Just a few internal
things like the token parser and some others are
only available as C code. We can either keep then
as they are, or re-code them in Python.
It is even thinkable to make certain existing
language features pluggable an configurable.

But again, thats future matters. Right now we
need to get all available Pyhton code to run.
That means to implement the minimum core that's
needed, and don't mess with the language.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/