[ann] Minimal Python project

[Paul Rubin]

Christian Tismer <tismer at tismer.com> writes:
> Opcode dispatch is expensive, so I have to create effective opcodes
> with direct parameter access.  But maybe you're right and it
> shouldn't be MMIX.

I remember seeing a paper once about OpenGenera which was a
proprietary (not "open" despite its name) program to run Symbolics
Genera programs on the DEC Alpha by simulating the Lisp machine
instruction set.  It basically said they found that by making the
simulation's interpreter loop and register set small enough to fit in
the Alpha's primary caches it ran as fast as they'd expect microcode
to run.  

> Maybe further that this absolutely doesn't matter at all: Any
> working virtual machine *would do it*, since we finally want to
> create code for the target hardware, and the virtual must only work
> for the bootstrapping phase. (Well, it should load the real engine
> in finite time :-)

Yes, that's reasonable too.

> [Language extensions]
> 
> > I think that local declarations and type hints are useful language
> > improvements for more reasons than helping generate fast code...
> 
> You are right.
> There are some reasons why I don't want to go this
> way right from the beginning:
> You have started this thread once and it went nowhere.
> I also remember of many threads concerning type
> notations and interfaces and whatsoever.
> They all went into some doomed state after burning
> many hours of thinking and writing.

Yes, if you want to implement an extension of this type it's better to
just pick out a way to do it and code it up, than to spend weeks
posting netnews about different possible methods.  There's also a nice
characteristic of experimental implementations, that if you don't like
how a feature works out, you can change it, unlike if it gets into a
real Python release and people start depending on it.  However, I can
understand your approach of wanting to leave it out completely at
first and possibly add it later if it's needed.

> I just don't want to loose much time now.  If we start changing
> Python before implementing something, then I fear this project will
> die out because we get stuck in the same discusions, again.  Better
> to go without hints and languages improvements as much as
> possible. This makes the project much less vulnerable.

I think you should feel willing to take some liberties with the
language if it makes your implementation cleaner.  A lot of the weird
corners of Python seem to me to be implementation hacks based on
CPython internals anyway.  Plus, I've mentioned that coding in Python
gives me something like the joy that I imagine that the 1960's Lisp
hackers must have felt.  The language itself is in similar shape to
1960's Lisp, with just two implementations (CPython and Jython), both
of them interpreters.  If the development of native-code Python
compilers results in some language evolution like it did for Lisp,
that's natural and not a bad thing.  However, it all depends on what
your goals are.  I don't personally see a pure, faithful, exact
reimplementation of a static target whose existing implementation is
free and works perfectly well on a wide range of platforms as being
something I'd want to devote precious volunteer energy to.  It's much
more interesting to be able to expand the boundaries of what's been
done before (as Stackless expanded boundaries).  However, YMMV.