[ann] Minimal Python project

[Christian Tismer]

Paul Rubin wrote:
> Christian Tismer <tismer at tismer.de> writes:

[about MMIX]

> Native compilers are good and a generic VM are good, but modelling the
> generic VM after MMIX doesn't seem like such a great choice.  Why not
> just a simple threaded or byte-code interpreter similar to the
> intermediate code of the compiler?  MMIX is a 64-bit machine with 256
> registers and simulating it with a 32-bit machine might be much slower
> than using a stack based VM.

Well, I was keen on trying MMIX out, although it is
in fact not the simplest possible approach. Also the
64 bit property is a bit much in the future.
One ide was to use this target engine, in preparation
for real upcoming 64 bit engines like MMIX.

Maybe this should be considered again.

On bytecode and stack machines:
No, I'm not convinced that these are slower than
register engines. Instead, I'd like to use a 3-address
register engine (and that's why MMIX came into the
play), since an interpreter for that can be written
much more efficiently than for a byte code stack
engine. It does not make sense to do all the stack
manipulations in an interpreter written in C, when
it is possible to address the stack like a register
file, IMHO.

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.

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 :-)

> Heck, maybe you could even emit C code and compile it externally, sort
> of like Kyoto Common Lisp (now AKCL/GNU Common Lisp) does.

Yes, this is another alternative for bootstrapping.

[Language extensions]

> I think that local declarations and type hints are useful language
> improvements for more reasons than helping generate fast code.  They
> can also help application programmer avoid bugs.  The compiler can
> flag undeclared variables (similar to perl's very worthwhile directive
> "use strict") and it can (in non-optimizing mode) emit code to check
> that all the type advice is correct at runtime and throw an exception
> if the advice fails.  If these features were present in Python I'd use
> them all the time.  But I started a clpy thread about it some time
> back and it went nowhere.

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.

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.

As soon as we see a dead end without adding hints to
the language, then we can try ways how to include
them. If they are needed, they will come into existence,
without blowing all the energy into mailing lists
for no result.

all the best -- 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/