[ann] Minimal Python project
holger krekel
--------------------------------------------
We announce a mailinglist dedicated to developing
a "Minimal Python" version. Minimal means that
we want to have a very small C-core and as much
as possible (re)implemented in python itself. This
includes (parts of) the VM-Code.
Building on the expected gains in flexibility
we also hope to use distribution techniques such
as PEP302 to ship only a minimal set of modules
and load needed modules on demand.
As Armin Rigo of PSYCO fame takes part in the effort,
we are confident that MinimalPython will eventually
run faster than today's CPython.
And because Christian Tismer takes part, we are
confident that we will find a radical enough
approach which also fits Stackless :-)
We are very interested in learning about and
integrating prior art. And in hearing any
doubtful or reinforcing opinions. Expertise
is welcomed in all areas.
So if you have an interest or even code regarding
'minimal python' please join the list:
http://codespeak.net/mailman/listinfo/pypy-dev
discussions previously took place on python-de and
in private mails. We will repost some core
ideas (in english) for further discussion.
In a few months we'd like to do a one-week
Sprint in Germany focusing on releasing first
bits of Minimal Python.
best wishes,
Armin Rigo,
Christian Tismer,
Holger Krekel
Stuart D. Gathman
> We announce a mailinglist dedicated to developing a "Minimal Python"
> version. Minimal means that we want to have a very small C-core and as
> much as possible (re)implemented in python itself. This includes (parts
> of) the VM-Code.
For those who haven't already looked at it, you might get some ideas from
the open source IBM project that is doing the same thing for Java:
http://www.research.ibm.com/jalapeno/
--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
Edward K. Ream
we are confident that MinimalPython will eventually
run faster than today's CPython.
This announcement seems to be making a truly remarkable claim, namely that
one could increase the speed of C code by recoding it in Python and then
applying Psycho to it.
I am inclined to disbelieve this claim. Why should Psycho be able to do
better than an optimizing C compiler applied to hand-written interpreter
code and/or library code? The only possibilities I can think of:
1. The GIT somehow has access to enough run-time information to perform some
truly excellent optimizations.
2. The granularity of the data processed by the GIT somehow is big enough to
again affect some excellent optimizations.
3. There are other marvelous optimizations, unknown to me and available
neither to Guido nor to an optimizing compiler that can be applied.
My guess is that none of these are true. Furthermore, I suspect that if
such optimizations are available to the GIT the optimizations could also be
made available either to Guido or to optimizing C compilers. Note that the
fact that Psycho can improve Python code is not, by itself, an indication
that it could improve the corresponding C code!
Would anyone care to enlighten me how MinimalPython will achieve its stated
goals?
Edward
--------------------------------------------------------------------
Edward K. Ream email: edr...@tds.net
Leo: Literate Editor with Outlines
Leo: http://personalpages.tds.net/~edream/front.html
--------------------------------------------------------------------
Erik Max Francis
> This announcement seems to be making a truly remarkable claim, namely
> that
> one could increase the speed of C code by recoding it in Python and
> then
> applying Psycho to it.
>
> I am inclined to disbelieve this claim. Why should Psycho be able to
> do
> better than an optimizing C compiler applied to hand-written
> interpreter
> code and/or library code?
I am inclined to disbelieve it as well. I'm no expert in Psyco, but I
think its realm of utility may be being taken too far here. I'm
reminded of the old gag about "It's turtles all the way down."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The more violent the love, the more violent the anger.
\__/ _Burmese Proverbs_ (tr. Hla Pe)
Sade Deluxe / http://www.sadedeluxe.com/
The ultimate Sade encyclopedia.
Chad Netzer
> > As Armin Rigo of PSYCO fame takes part in the effort,
> > we are confident that MinimalPython will eventually
> > run faster than today's CPython.
> I am inclined to disbelieve this claim. Why should Psycho be able to
> do better than an optimizing C compiler applied to hand-written
> interpreter code and/or library code?
Perhaps because the hand-written code is not tuned for speed, and not
easily optimized by a C compiler for ultimate speed. The Python code
makes a number of clever optimization regarding memory allocation and
other issues, but in general, it goes for straightforward, portable
design, rather than lots of fancy optimization tricks.
Someone trying to make the fastest C version possible of Python, may be
able to do much better, but it could be a lot of work (and in
particular, may require converting a lot of existing Python code into
C), without being more maintainable or portable. Currently, a LOT of
the Python Library is implemented in Python, not C.
> Would anyone care to enlighten me how MinimalPython will achieve its
> stated goals?
Take a look at Psyco. It tries to produce faster runtime code based on
evaluation of runtime characteristics. Ie. it specializes at runtime,
rather than compilation. This is a whole different class of optimizing
than C compilers are traditionally doing, and has had some good results
(apparently) so far.
So whether or not the new project will be faster than CPython, I don't
know. But there is ample evidence to suggest that the claim that it
could be faster, is not hollow.
http://psyco.sourceforge.net/introduction.html
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
cne...@mail.arc.nasa.gov
holger krekel
> > As Armin Rigo of PSYCO fame takes part in the effort,
> we are confident that MinimalPython will eventually
> run faster than today's CPython.
>
> This announcement seems to be making a truly remarkable claim, namely that
> one could increase the speed of C code by recoding it in Python and then
> applying Psycho to it.
Sure, you can't generally get faster than C code. But then,
we just said faster than CPython (and note 'eventually').
Armin Rigo gives some ideas in
http://psyco.sourceforge.net/plans.html
why a Python core can be faster. Basically, PSYCO can't
currently do as much with the frame object and Interpreter
(in ceval.c) as it would like to.
> I am inclined to disbelieve this claim. Why should Psycho be able to do
> better than an optimizing C compiler applied to hand-written interpreter
> code and/or library code? The only possibilities I can think of:
>
> 1. The GIT somehow has access to enough run-time information to perform some
> truly excellent optimizations.
PSYCO currently emits Machine code if it has gathered enough
information. Several statements can (in extreme cases) collaps
into one machine instruction. Armin explained at EuroPython
that this is more a side effect than the result of deeply magic
special optimizations.
I leave further and more detailed discussion to Armin on the
pypy list. There already have been quite some repetitions
of issues and that is the reason for the mailing list in
the first place.
But please note that speed probably won't be the first
goal for quite some time, anyway.
regards,
holger
Andrew McGregor
--On Friday, January 10, 2003 23:37:09 +0000 "Edward K. Ream"
<edr...@tds.net> wrote:
>> As Armin Rigo of PSYCO fame takes part in the effort,
> we are confident that MinimalPython will eventually
> run faster than today's CPython.
>
> This announcement seems to be making a truly remarkable claim, namely that
> one could increase the speed of C code by recoding it in Python and then
> applying Psycho to it.
Yep, you can! It takes a pretty strange piece of code, but it does happen.
For instance, I've written a key-management protocol in Python, and it
really is faster than the C implementations of the same thing when certain
key functions are fed to psyco. (of course, this may just say that I have
a better feel for algorithm design)
> I am inclined to disbelieve this claim. Why should Psycho be able to do
> better than an optimizing C compiler applied to hand-written interpreter
> code and/or library code? The only possibilities I can think of:
>
> 1. The GIT somehow has access to enough run-time information to perform
> some truly excellent optimizations.
This one :-) For instance, in a dynamic language, you can't know until
runtime if some argument to a method has constant type or (better) constant
value, but a JIT can discover and use this. If it does not, and someone
passes it a different type or value, the JIT can then discover this and
compile a new version that handles that type, optimised. Note that the
constant value case can't be optimised by a C compiler, unless the function
is inlined, which doesn't happen in big programs very much because the
function will often be in another module.
It is also possible to inline method calls, merge methods if they are often
called in a particular sequence, and then optimise over the results. C
compilers, because of modular compilation again, often can't do this either
(although a particularly fancy compiler might; it needs an integrated build
system to make this possible).
> 2. The granularity of the data processed by the GIT somehow is big enough
> to again affect some excellent optimizations.
Maybe so, I'm not sure.
> 3. There are other marvelous optimizations, unknown to me and available
> neither to Guido nor to an optimizing compiler that can be applied.
>
> My guess is that none of these are true. Furthermore, I suspect that if
> such optimizations are available to the GIT the optimizations could also
> be made available either to Guido or to optimizing C compilers. Note
> that the fact that Psycho can improve Python code is not, by itself, an
> indication that it could improve the corresponding C code!
>
> Would anyone care to enlighten me how MinimalPython will achieve its
> stated goals?
>
> Edward
> --------------------------------------------------------------------
> Edward K. Ream email: edr...@tds.net
> Leo: Literate Editor with Outlines
> Leo: http://personalpages.tds.net/~edream/front.html
> --------------------------------------------------------------------
>
>
yaipa h.
While I am gripped in fear at the thought of Python spinning into a
series of downward spiraling dialects...
The adventurer in me says, "Give'em hell boys... Damn the
torpedoes..."
-al
]Andrew McGregor <and...@indranet.co.nz> wrote in message news:<mailman.104225719...@python.org>...
Edward K. Ream
> > that one could increase the speed of C code by recoding it in Python
> > and then applying Psycho to it.
>
> Sure, you can't generally get faster than C code. But then,
> we just said faster than CPython (and note 'eventually').
> Armin Rigo gives some ideas in
>
> http://psyco.sourceforge.net/plans.html
Many thanks for this link. Actually, these slides do propose a method that
might be faster that the C _interpreter_ code. As such they seem to be
supporting the "truly remarkable" claim. I shall look forward to the full
paper with keen interest.
Edward
Edward K. Ream
> > that one could increase the speed of C code by recoding it in Python
> > and then applying Psycho to it.
> Yep, you can! It takes a pretty strange piece of code, but it does
happen.
> For instance, I've written a key-management protocol in Python, and it
> really is faster than the C implementations of the same thing when certain
> key functions are fed to psyco. (of course, this may just say that I have
> a better feel for algorithm design)
Even with the caveat about the algorithm, such a result is indeed "truly
remarkable". Thanks for this information.
> For instance, in a dynamic language, you can't know until
> runtime if some argument to a method has constant type or (better)
> constant value, but a JIT can discover and use this. If it does not,
> and someone passes it a different type or value, the JIT can then discover
> this and compile a new version that handles that type, optimised.
> Note that the constant value case can't be optimised by a C compiler,
> unless the function is inlined, which doesn't happen in big programs very
> much because the function will often be in another module.
I was referring to something like this when I wrote point 1. Still, it is
amazing
that something like this could be so effective. I suppose in time all of
our
instincts will be revised by psycho. Still, I'll believe it when I see it
:-)
Edward
John Roth
"Edward K. Ream" <edr...@tds.net> wrote in message
news:%0TT9.121156$Hs2.11...@kent.svc.tds.net...
The actual proof is in Java runtimes. They all seem to use JIT
compilers,
and they wind up being quite effective at speeding up the pig. And of
course this is nothing new, relational data bases would be a curiosity
if they didn't have query optimizers. They'd just be too darned slow
for general use.
John Roth
Peter Hansen
>
> > As Armin Rigo of PSYCO fame takes part in the effort,
> > we are confident that MinimalPython will eventually
> > run faster than today's CPython.
>
> This announcement seems to be making a truly remarkable claim, namely that
> one could increase the speed of C code by recoding it in Python and then
> applying Psycho to it.
>
> I am inclined to disbelieve this claim. Why should Psycho be able to do
> better than an optimizing C compiler applied to hand-written interpreter
> code and/or library code? The only possibilities I can think of:
I'm inclined to withhold judgment on such claims, admitting the
possibility that I don't know everything.
This inclination comes from an event in my distant past, around grade seven,
when a friend of mine named Simon Gibson(*) and I were walking home from
school one day and he told me that, with one of those new-fangled C
compilers, it was possible to write code that ran *faster* than assembly
language! Pshaw! What a load of hogwash, said I. How could one possibly
get code that ran faster assembly, the *fastest* language around, by
writing it in a high-level language and having a compiler turn it into
assembly!? I was inclined to disbelieve the claim.
After a while, Simon convinced me that, with optimizations that I
as an assembly programmer would never make (at the time, it wasn't a
case of avoiding bad style, since one did anything one could to get fast
code, but simply a case of not thinking of the optimization trick),
a C compiler would indeed, someday, generate faster assembly than I could.
I manage to get him to concede that an expert assembly programmer
*might* then be able to tweak the resulting code, in special cases,
to be even faster, but I eventually accepted his claim. And, of course,
eventually C compilers _were_ able to optimize and his point was proven.
Then there was the guy who said that no one would ever need more than
640K of RAM...
And then there was the HotSpot compiler for Java, which I was inclined
to disbelieve could ever produce faster code than those optimizing
C compilers.
I no longer believe it's wise to disbelieve claims so quickly...
I also think it *is* a good idea to express support for such novel
and pioneering efforts, when someone is willing to invest the time
needed to *try* to make it work, and willing to risk failure.
Those of us willing to sit on the sidelines should be supportive, IMHO.
-Peter
(*) Simon was, sadly, killed in a climbing accident during a co-op
work-term at Microsoft. (Another thing I've never forgiven them for. ;-)
Edward K. Ream
> possibility that I don't know everything.
A better rule of thumb, IMO, is that extraordinary claims require
extraordinary justification.
Edward K. Ream
> compilers,
> and they wind up being quite effective at speeding up the pig.
If JIT's are so effective, why are the swing classes so slow?
holger krekel
> > I'm inclined to withhold judgment on such claims, admitting the
> > possibility that I don't know everything.
>
> A better rule of thumb, IMO, is that extraordinary claims require
> extraordinary justification.
We probably should have said 'hope to' instead of
'are confident' regarding speed prospects.
Edward, i appreciate your scepticism as it reminds me
that we are mostly doing this because we want to have fun
while trying it. Raising too many expectations can be
dangerous. Now, rumor has it that Armin Rigo will
also do it as part of his new job and he is (still :-)
confident so hopefully, 'eventually' this will work out.
cheers,
holger
John Roth
> > The actual proof is in Java runtimes. They all seem to use JIT
> > compilers,
> > and they wind up being quite effective at speeding up the pig.
>
> If JIT's are so effective, why are the swing classes so slow?
Think of how slow they'd be without the JIT compilers! After all,
they're doing in Java what any sane package does in C with
assembler assists.
John Roth
John Roth
> > I'm inclined to withhold judgment on such claims, admitting the
> > possibility that I don't know everything.
>
> A better rule of thumb, IMO, is that extraordinary claims require
> extraordinary justification.
Whether or not a claim is extraordinary is totally in the mind (if
any) of the person who dislikes the claim.
John Roth
Paul Rubin
> I am inclined to disbelieve this claim. Why should Psycho be able to do
> better than an optimizing C compiler applied to hand-written interpreter
> code and/or library code? The only possibilities I can think of:
>
> 1. The GIT somehow has access to enough run-time information to perform some
> truly excellent optimizations.
> 2. The granularity of the data processed by the GIT somehow is big enough to
> again affect some excellent optimizations.
> 3. There are other marvelous optimizations, unknown to me and available
> neither to Guido nor to an optimizing compiler that can be applied.
Fourth possibility: The CPython implementation, while highly flexible,
is not especially fast, and a faster interpreter can be written by
using different implementation techniques. Also, it wasn't clear to
me but perhaps Minimal Python will include a native-code compiler
(Psyco-based or otherwise).
I've had the idea for a while that a "minimal" Python should actually
include some language extensions to improve execution speed. For
example, being able to declare local variables and give type advice to
the compiler (like Lisp systems do) can make it possible to early-bind
class methods and slots to their callers. That can avoid an awful lot
of dictionary lookups and speeds things up considerably.
Edward K. Ream
news:mailman.1042312221...@python.org...
Thanks very much for this clarification. Fun is one of the most powerful,
creative and useful emotions there is. I think it is one of the very best
reasons for doing any project :-)
Perhaps I wasn't clear enough myself in my original posting. My attitude at
present is a mixture of a) extreme interest and b) moderate skepticism.
Given the potential payoffs, this is a project that ought to be pursued.
Let us suppose for the moment that it is indeed possible to improve the
speed of the C interpreter using some kind of GIT applied to Python code.
Obviously, this would be extremely important to all Python programmers.
Moreover, such a strategy might be important in the larger world. For
instance, it might suggest new kinds of hardware design: maybe novel caching
techniques or new machine architectures oriented towards higher-level
languages. Such ideas were tossed around decades ago; perhaps their time
has come again. Certainly compiler vendors would be very interested as
well.
These implications might be interpreted more pessimistically. Designers of
hardware, gits and compilers have put a lot of time, thought and money into
their work; perhaps the fact that run-time optimizations have not yet been
spectacularly successful is some clue that they can't be made so. OTOH,
perhaps Armin is on to something that will revolutionize many parts of the
computing world.
But these are all speculations. The intent of my original posting was to
get as much information as possible about _how_ and _why_ this project can
speed up Python's interpreter. I focused on my doubts because they point to
the kinds of questions I would like to see answered. To repeat: I eagerly
await a more detailed presentation of the technical details. Some things
I'd like to see in the presentation:
- a detailed overview of the design of the GIT
- a detailed overview of the actual code of the GIT
- detailed examples of how to speed up the interpreter, with real code
examples
- as many real-world statistics as possible
- a discussion of the limitations of the technique, if any
- anything else that would help us understand how and why the optimizations
are effective.
And as long as I am asking, I would like to see a real technical paper, not
just PowerPoint slides. Thanks again, Holger, for your good humored answer.
Edward K. Ream
>
> Think of how slow they'd be without the JIT compilers! After all,
> they're doing in Java what any sane package does in C with
> assembler assists.
I am _not_ denying that JIT's can speed up code! I am raising doubts about
whether any JIT can produce results superior to hand-written C code. The
two issues are completely different!
Edward K. Ream
> > > possibility that I don't know everything.
> >
> > A better rule of thumb, IMO, is that extraordinary claims require
> > extraordinary justification.
>
> Whether or not a claim is extraordinary is totally in the mind (if
> any) of the person who dislikes the claim.
This statement is false. If it were true we would have no basis on which to
judge any claim at all.
I believe I am discussing this issues on the merits. And I have never said
I "dislike" the claim. I have said only that I have doubts about it.
Indeed, I would be thrilled if the claim were true.
Terry Reedy
"John Roth" <john...@ameritech.net> wrote in message
news:v2111cf...@news.supernews.com...
>
> "Edward K. Ream" <edr...@tds.net> wrote in message
> news:SrZT9.121191$Hs2.11...@kent.svc.tds.net...
> > extraordinary justification.
>
> Whether or not a claim is extraordinary is totally in the mind (if
> any) of the person who dislikes the claim.
There are people who claim they can fly (levitate) by meditating, or
by willing it so. I think it would be wonderful (I even tried it as a
kid). But given the lack of any credible public demonstration
anywhere, anytime, I feel comfortable in regarding it as an
'extraordinary' claim. And in wanting to see such a feat in person
before I really, really believed it.
Terry J. Reedy
Neil Hodgson
> If JIT's are so effective, why are the swing classes so slow?
Library design, particularly the features, algorithms and data structures
chosen, is much more important than the underlying language interpretation
speed. You can see this in the different speeds of C++ GUI toolits on a
given platform. An example current performance issue is the slowdown
toolkits take on Linux/X for using Unicode - GTK+ 2 is quite a bit slower
than GTK+ 1.
Neil
Peter Hansen
>
> > > If JIT's are so effective, why are the swing classes so slow?
> >
> > Think of how slow they'd be without the JIT compilers! After all,
> > they're doing in Java what any sane package does in C with
> > assembler assists.
>
> I am _not_ denying that JIT's can speed up code! I am raising doubts about
> whether any JIT can produce results superior to hand-written C code. The
> two issues are completely different!
I believe it's actually not the case that a JIT compiler will generally
produce faster code than hand-written C. JIT compilers have a trade-off
between speed of the generated code, and speed of the code generation --
they must finish quickly because they have to run at startup.
As I understand it, a compiler like the Java HotSpot compiler, however,
*can* produce results better than hand-written C, and the reason should
be fairly clear: in addition to having more time to execute because it
doesn't reduce invocation time, a compiler like that has the advantage
of being able to analyze the code *in the current dynamic context*
where it is running. The C compiler has no knowledge of the conditions
that will exist when the code runs. Even if it did, its job is
already done, while the HotSpot compiler can run again, and again,
tuning the application as conditions change.
Now if you want to argue *still* that hand-written C code based
on a careful analysis of the dynamic situation to be expected,
and designed automatically to adapt as conditions change can always
be made faster than what something like HotSpot can produce, then
I would say you're making the same argument I made 23 years ago
about Assembler versus optimizing C compilers, and the answer
is the same: *practically* it's irrelevant because only in extremely
rare circumstances can one afford to take the time to optimize
or design that carefully, while the HotSpot compiler can do it
in general "for free".
-Peter
Christian Tismer
Don't forget that I've proven that I can
change truth, and I'm in the group from
the beginning (actually I caused it to begin).
I am very convinced that this project is able
to lead to a Python implementation that has
a smaller code base with a minimum of C code,
and that runs faster than CPython.
And it will be Stackless by nature.
I don't claim that this will be the result of
a single sprint. But this is my goal.
if-it-is-possible-at-all-then-we-will-make-it - ly y'rs - chris
--
Christian Tismer :^) <mailto:tis...@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/
Paul Rubin
> I am very convinced that this project is able to lead to a Python
> implementation that has a smaller code base with a minimum of C
> code, and that runs faster than CPython. And it will be Stackless
> by nature. I don't claim that this will be the result of a single
> sprint. But this is my goal.
I don't doubt that it's possible. That's not meant as any kind of
slight on the CPython implementers, but it's there are always great
benefits to doing something a second time around.
In my dreams we'd have a completely self-hosted Python implementation
that compiles to native code on the fly, sort of like the Yale T system.
Gerhard Häring
> Don't forget that I've proven that I can change truth, [...]
>>> True, False = False, True
>>> True, False
(0, 1)
Easy enough ;-)
SCNR,
-- Gerhard
Christian Tismer
> "Edward K. Ream" <edr...@tds.net> writes:
>
>>I am inclined to disbelieve this claim. Why should Psycho be able to do
>>better than an optimizing C compiler applied to hand-written interpreter
>>code and/or library code? The only possibilities I can think of:
>>
>>1. The GIT somehow has access to enough run-time information to perform some
>>truly excellent optimizations.
>>2. The granularity of the data processed by the GIT somehow is big enough to
>>again affect some excellent optimizations.
>>3. There are other marvelous optimizations, unknown to me and available
>>neither to Guido nor to an optimizing compiler that can be applied.
>
>
> Fourth possibility: The CPython implementation, while highly flexible,
> is not especially fast, and a faster interpreter can be written by
> using different implementation techniques. Also, it wasn't clear to
> me but perhaps Minimal Python will include a native-code compiler
> (Psyco-based or otherwise).
CPython is optimized towards portability, not speed.
The algorithms are clean and fast, but like every
implementation, it is written as one big compromize.
The C code base cannot adapt itself to changed
runtime demands.
With a generic approach like Psyco, there are
optimizations and specializations possible, where
a C programmer wouldn't even think of, or would
simply hesitate to implement, since this would
make the code so much harder to maintain.
For my planning (which is just where I'd like to
go, but maybe the group will decide otherwise),
there will be a native compiler version for every
platform, finally.
But I'm also thinking of a generic virtual machine,
modelled after Knuth's MMIX engne, which should
run on any platform.
> I've had the idea for a while that a "minimal" Python should actually
> include some language extensions to improve execution speed. For
> example, being able to declare local variables and give type advice to
> the compiler (like Lisp systems do) can make it possible to early-bind
> class methods and slots to their callers. That can avoid an awful lot
> of dictionary lookups and speeds things up considerably.
This is the very last thing I'm thinking of.
In the first place, I want to go as far as possible
with runtime deducible conclusions. When that
principle gets stuck, we should consider to
implement hints.
ciao - chris
Manuel M. Garcia
<py...@devel.trillke.net> wrote:
(edit)
>We probably should have said 'hope to' instead of
>'are confident' regarding speed prospects.
Yeah, I got nervous when I read "we are confident that MinimalPython
will eventually run faster than today's CPython".
It reminded me of the "microthread OS" and "Perl 6 Parrot registers VM
versus stack VM". Before coding even begins, performance claims are
made, mainly based on the "coolness" of the technique. When the
performance does not materialize, or the coding is stalled, the
technique is still treated as above reproach. And when the old way is
still faster, pleading that will more time, and with more coders, the
old way will be left in the dust.
I can see how MinimalPython could be faster than CPython. No
programmer would write C code tuned to run optimally on every machine
under every different multi-tasking work load with every different
internal state. Too many machines, too many ways of trading space for
speed, too many ways of striving for something small enough to fit in
the cache and avoid paging, too many different tricks. Of course, a
sane C programmer would write a single reasonably efficient
implementation, and in the program's hot spots, maybe specialized code
to take advantage of a few common situations.
A JIT compliler would supply code tuned for the specific machine in
the specific situation. It might be different low level code each
time, but the JIT compliler does not care.
The part of the project I am most excited about is playing with a
reasonalbly efficient Python implementation written mainly in Python!
If the speed never materializes, we still have a test bed for many
Python programmers to try out new ideas for the traditional Python
implementations. And if the speed claim comes true, that is a whole
another level of goodness!
Manuel
John Roth
"Manuel M. Garcia" <mga...@cole-switches.com> wrote in message
news:dgb12von92hgnkrqm...@4ax.com...
What about writing it *entirely* in Python?
I'm currently playing around with Squeak, which is a Smalltalk
variant whose interpreter is written entirely in a subset of Smalltalk
that can be machine translated to portable C!
John Roth
>
> Manuel
Mike Meyer
> The C compiler has no knowledge of the conditions that will exist
> when the code runs. Even if it did, its job is already done, while
> the HotSpot compiler can run again, and again, tuning the
> application as conditions change.
That's not strictly true. I've dealt with compilers that could examine
the results of profiled runs of the code being compiled, and use that
information in optimizing the resulting code. You could even rerun the
profiled version on new data and recompile the code.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Paul Rubin
> For my planning (which is just where I'd like to go, but maybe the
> group will decide otherwise), there will be a native compiler
> version for every platform, finally. But I'm also thinking of a
> generic virtual machine, modelled after Knuth's MMIX engne, which
> should run on any platform.
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.
Heck, maybe you could even emit C code and compile it externally, sort
of like Kyoto Common Lisp (now AKCL/GNU Common Lisp) does.
> > I've had the idea for a while that a "minimal" Python should actually
> > include some language extensions to improve execution speed. For
> > example, being able to declare local variables and give type advice to
> > the compiler (like Lisp systems do) can make it possible to early-bind
> > class methods and slots to their callers. That can avoid an awful lot
> > of dictionary lookups and speeds things up considerably.
>
> This is the very last thing I'm thinking of. In the first place, I
> want to go as far as possible with runtime deducible
> conclusions. When that principle gets stuck, we should consider to
> implement hints.
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.
Peter Hansen
>
> Peter Hansen <pe...@engcorp.com> writes:
>
> > The C compiler has no knowledge of the conditions that will exist
> > when the code runs. Even if it did, its job is already done, while
> > the HotSpot compiler can run again, and again, tuning the
> > application as conditions change.
>
> That's not strictly true. I've dealt with compilers that could examine
> the results of profiled runs of the code being compiled, and use that
> information in optimizing the resulting code. You could even rerun the
> profiled version on new data and recompile the code.
Thanks, I had never heard of such a thing.
It doesn't help in many cases, however, since conditions are often
dynamic, and doing profiling runs on your server and recompiling
it, stopping, upgrading, and restarting it just to improve its
performance under changing conditions is probably infeasible... ;-)
-Peter
Martijn Faassen
> Still, I'll believe it when I see it
Me too. And I happen to know that these are some smart people working
on it. I'm very happy to hear about this project.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Arne Koewing
> Mike Meyer wrote:
>>
>> Peter Hansen <pe...@engcorp.com> writes:
...
>> That's not strictly true. I've dealt with compilers that could examine
>> the results of profiled runs of the code being compiled, and use that
>> information in optimizing the resulting code. You could even rerun the
>> profiled version on new data and recompile the code.
>
> Thanks, I had never heard of such a thing.
with the newest gcc you could also do that... :-)
Arne
Steve Holden
[Holger]
> > As Armin Rigo of PSYCO fame takes part in the effort,
>
> This announcement seems to be making a truly remarkable claim, namely that
> one could increase the speed of C code by recoding it in Python and then
> applying Psycho to it.
>
> better than an optimizing C compiler applied to hand-written interpreter
[...]
>
> Would anyone care to enlighten me how MinimalPython will achieve its
stated
> goals?
>
In more or less the same way that a good C compiler nowadays tends to
produce code that out-performs an algorithm coded in assembly language by a
moderately-competent programmer?
regards
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Bring your musical instrument to PyCon! http://www.python.org/pycon/
Christian Tismer
> Christian Tismer <tis...@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
> Christian Tismer <tis...@tismer.de> writes:
>
>>I am very convinced that this project is able to lead to a Python
>>implementation that has a smaller code base with a minimum of C
>>code, and that runs faster than CPython. And it will be Stackless
>>by nature. I don't claim that this will be the result of a single
>>sprint. But this is my goal.
>
>
> I don't doubt that it's possible. That's not meant as any kind of
> slight on the CPython implementers, but it's there are always great
> benefits to doing something a second time around.
Thanks, this is very encouraging.
Yes, the current C implementation is probably
near the best compromise between readability,
maintainability and efficiency that can be
achieved with a static system.
To make substantial improvements possible, the
word "static" must go away.
> In my dreams we'd have a completely self-hosted Python implementation
> that compiles to native code on the fly, sort of like the Yale T system.
Never heard of this, but this is my dream, too.
ciao - chris
Neil Schemenauer
> Paul Rubin wrote:
>> In my dreams we'd have a completely self-hosted Python implementation
>> that compiles to native code on the fly, sort of like the Yale T system.
>
> Never heard of this, but this is my dream, too.
The history of T:
http://www.paulgraham.com/thist.html
Neil
Paul Rubin
> > That's not strictly true. I've dealt with compilers that could examine
> > the results of profiled runs of the code being compiled, and use that
> > information in optimizing the resulting code. You could even rerun the
> > profiled version on new data and recompile the code.
>
> Thanks, I had never heard of such a thing.
That's called "profile directed optimization" and if you type that
phrase into google you should be able to find lots of info.
Carl Banks
I disagree; I think profiling data can help optimize the compilation
quite a bit even under widely varying conditions, especially if enough
runs are done to get a kind of average. Even if that isn't true, a
lot of optimizing will occur in purely userspace parts of the program,
and these parts won't be affected by system load.
And of course it's feasable (usually) to collect profiling data for a
time, compile a newly tuned program on another computer, and update it
quickly during a maintenance period. A little networking magic and
there won't even be a downtime at all.
--
CARL BANKS
Carl Banks
> Thanks, this is very encouraging.
> Yes, the current C implementation is probably
> near the best compromise between readability,
You left out backwards compatibility.
> ... that can be
> achieved with a static system.
--
CARL BANKS
Paul Rubin
> 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.
Christian Tismer
> "Edward K. Ream" <edr...@tds.net> wrote ...
> [Holger]
>
>>>As Armin Rigo of PSYCO fame takes part in the effort,
>>
>>we are confident that MinimalPython will eventually
>>run faster than today's CPython.
>>
>>This announcement seems to be making a truly remarkable claim, namely that
>>one could increase the speed of C code by recoding it in Python and then
>>applying Psycho to it.
>>
>>I am inclined to disbelieve this claim. Why should Psycho be able to do
>>better than an optimizing C compiler applied to hand-written interpreter
>>code and/or library code? [...]
...
> In more or less the same way that a good C compiler nowadays tends to
> produce code that out-performs an algorithm coded in assembly language by a
> moderately-competent programmer?
Exactly.
A good C compiler outperforms a good assembly
programmer, since it is stubborn enough and able
to keep track of many registers and variables.
These are things that a programmer can probably
do better in the small, but not in the large.
But a C compiler creates static code.
A compiler which is able to figure out
the common cases at run-time and is able
to specialize, is more adaptive and thereby
can theoretically produce better code than
the static compiler. It also can adapt to
the actual CPU version much better, if we
support that.
This is of course not an easy job, and maybe
we will fail miserably for some reason.
But we will never know if we don't try.
There is at least a chance to take -- chris
Berthold Höllmann
Even better:
>python
Python 2.3a1 (#1, Jan 9 2003, 22:40:56)
[GCC 3.2 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True, False
(True, False)
>>> True, False = False, True
>>> True, False
(False, True)
True is false and false is true.
Berthold
--
bh...@web.de / http://starship.python.net/crew/bhoel/
It is unlawful to use this email address for unsolicited ads
(USC Title 47 Sec.227). I will assess a US$500 charge for
reviewing and deleting each unsolicited ad.
Paul Rubin
> >> In my dreams we'd have a completely self-hosted Python implementation
> >> that compiles to native code on the fly, sort of like the Yale T system.
> >
> > Never heard of this, but this is my dream, too.
>
> The history of T:
>
> http://www.paulgraham.com/thist.html
That's an interesting article--I hadn't seen it. The remark about
lexical scope being less efficient than dynamic scope of course
applies only to interpreters and not compilers (the whole point of
Scheme). RMS of course understood that since he implemented lexical
scope in Lisp Machine Lisp. And Steele understood it too--Scheme was
designed from the start to be compiled. (Emacs Lisp is just an
editing extension language and having a native-code compiler for it
would have been crazy).
The T history article may make it sound like a self-hosted system has
to be a massive undertaking, but I don't believe that's true, if
you're not trying to build an ultra-high-powered optimizing compiler.
The T source code is rather good inspirational reading (I'm sure you
can still download it from somewhere).
IIRC the etymology of Scheme-48 is that 48 is 84 spelled backwards--it
was supposed to be a simple implementation of Scheme-84.
I wish that some Lisp implementation gurus could get involved in
Python. A lot of Python semantics map very naturally onto Lisp, and
bringing Lisp compiler techniques to Python could make Python code
run blazing fast.
CMU Common Lisp's compiler, by complete coincidence, happens to be
called Python (maybe inspired by Rabbit, the name of the first Scheme
compiler). Another dream I have is to adapt CMUCL's Python compiler
to compiling the Python language, if for no other reason than to enjoy
the confusion that the name collision would cause ;-).
Christian Tismer
> Christian Tismer wrote:
>
>>Thanks, this is very encouraging.
>>Yes, the current C implementation is probably
>>near the best compromise between readability,
>>maintainability and efficiency ...
>
>
> You left out backwards compatibility.
Thank you, very true! I fogot to mention this.
>>... that can be
>>achieved with a static system.
With a dynamic system, you can have backwards
compatibility as well, together with the
flexibility to try alternatives on-the-fly
rather easily. Changing some very internal
things to try something out is still not
easy, but with welded C code, this is
almost impossible.
Thanks for pointing this good argument out!
Paul Rubin
> >>... that can be
> >>achieved with a static system.
>
> With a dynamic system, you can have backwards compatibility as well,
> together with the flexibility to try alternatives on-the-fly rather
> easily. Changing some very internal things to try something out is
> still not easy, but with welded C code, this is almost impossible.
Can you explain what you mean by static vs. dynamic?
Is PHP a static system or a dynamic one? I ask this because the PHP
interpreter has been benchmarked as quite a bit faster than Python.
Of course that must be partly because the PHP language doesn't use
abstract objects so extensively, so the interpreter doesn't have to do
as many dictionary lookups all the time.
Christian Tismer
Paul Rubin wrote:
> Christian Tismer <tis...@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.
I agree. With a real engine like an Alpha.
My target physical engine is clearly the
whole set of X86's which are dominating
the world (still).
I've written several small intepreters in C,
also tried to make some fast Forth interpreter,
and always found that the X86 doesn't have
enough registers to make a fast, interpreted
stack engine.
Whenever you try to get the C compiler to keep
your vital variables in registers, then you have
nearly nothing left to work with.
Maybe I could have optimized towards the primary
cache, I never did this.
By creating a register machine, I might have the
chance to get the register file into that cache,
and to have the interpreter loop variables in
registers, still.
Of course, programming a stack engine by hand is
much easier. But I'm not going to write assembly
code by hand. That's why I like Python - it will
do all the register spilling stuff for me.
I can access this engine from a very high level
and create efficient code.
(will stop this of course, when Armin is ready to
take over).
(answering the second part later)
ciao - chris
Christian Tismer
> Christian Tismer <tis...@tismer.com> writes:
>
>>>>... that can be
>>>>achieved with a static system.
>>
>>With a dynamic system, you can have backwards compatibility as well,
>>together with the flexibility to try alternatives on-the-fly rather
>>easily. Changing some very internal things to try something out is
>>still not easy, but with welded C code, this is almost impossible.
>
>
> Can you explain what you mean by static vs. dynamic?
Yes. Please see below.
> Is PHP a static system or a dynamic one? I ask this because the PHP
> interpreter has been benchmarked as quite a bit faster than Python.
> Of course that must be partly because the PHP language doesn't use
> abstract objects so extensively, so the interpreter doesn't have to do
> as many dictionary lookups all the time.
Sorry, I don't have enough insight into PHP to
answer that question. And I doubt I will ever
have that, since what I saw my son programming
in PHP was much too perlish to invoke my interest :-)
(although I'm happy to see him programming at all,
hoping he will get back to Python in some future.
At the moment, he's trying to distinguish form his
father, which I can understand...)
I will try to explain my current perception of
static and dynamic in the context of building
a Python compiler. Please excuse that I'm writing
out of the top of my head. This is more a feeling
than exact information. Somebody will augment this
for sure, and I appreciate it.
What is STATIC?
---------------
Regardles of PHP (someone more enlighted may judge this),
by static I mean something like a C compiler, which is
fed by a number of C sources, which are fixed at some
compile time, with no chance to get changed.
There is exactly one build process, which leads to
an executable, and that's it. From then on, this
executable has to fit everything, for every application
and for all time, until another version is compiled.
The static executable is also almost always not
optimized for the platform, the processor brand,
the amount of physical memory available, and the
applications to be run.
Finally, the static build is also dependant of a C
compiler created by somebody, where it has no real
control about. This is especially true for closed
source platforms like Windows, but also open sourced
compilers like the gcc family are huge projects,
very difficult to understand for average programmers
like me, so they are black holes as well. That makes
optimizations into something like a try and error
game instead into a scientific project.
I admit that the last argument is not specific to
the static tag, it is just an observation that
comes for free. Implementing one's own system,
specifically designed towards the language to implement
and not trying to solve the world's needs for a compiler
surely creates an easier to understand and optimize
tool.
What is DYNAMIC?
----------------
Dynamic means to avoid compling lots of your system
based upon a fixed set of C sources, with some typical
C compiler. You try to avoid C at all. Instead, you
try to express as much as possible with a language
that is dynamic by nature (for the implicit definition
of dynamicness every Python programmer should feel).
You rely on the fact that your Python code will be
fed into a specializing compiler which is able to
do several things which a C compiler normally cannot
do:
- The executed code is analyzed at runtime. This gives
the compiler the opportunity to optimize code driven
by the needs of the actual application. This can lead
to very different implementation of certain interpreter
activities, in a very application dependant manner.
- The machine code can be created with knowledge of the
actual hardware platform, to any thinkable extent!
If there is a machine specification available that
matches the current hardware, every speciality of the
hardware can be used for optimization. To my knowledge,
there is no such extensive optimization available at
this time, but it is possible and likely to appear.
The compiler can take measures of cache lines, main
memory size and access time, special register sets
in the CPU, everything is possible.
This is out of the scope of a static C compiler.
- By avoiding the so-called C runtime system, or minimizing
it to the absolutely necessary, the fence between
Python code and library implementation of Python objects
vanishes. This opens these things to optimization at
runtime. There is no longer a Python interpreter, written
in C, and a set of Python objects, implemented in C, with
the interpreter calling methods of these objects.
Instead, the optmization of the interpreter (written in
Python) can dynamically decide, wheather it makes
sense to call a method of certain objects in a
pre-defined manner, or it can try a specialized
version of that method (again written in Python),
and it can implement this method inlined into the
specialized version of the interpreter,
that makes sense in just that current context.
A C compiler has no chance to do something comparable,
simply because it does not have the runtime info,
but especially since it has no idea of Python at all!
By writing almost everything in Python, we are able
to generate every possible optimization, since we still
have the full knowledge of the abstractions, of what we
wanted to implement, of our objects and of our targets.*
This is what I call 'dynamic', and this is what I hope
to be the
__future__ of Python
dynamically y'rs -- chris
P.s.: *
This is btw. something that would be lost by using
macros, unless we invent a macro language which does
know what it is doing. Almost all macro language I've
seen so far did a dumb textual or tuple replacement.
This is what language designers do when they don't know
how to continue.
Macros are a powerful extension to weak languages.
Powerful languages don't need macros by definiton.
Christian Tismer
> Christian Tismer <tis...@tismer.com> writes:
Now I'm trying to do my second answer to this.
>>>I think that local declarations and type hints are useful language
>>>improvements for more reasons than helping generate fast code...
[me, arguing against introduction of new features,
introducing many fruitless discussions...]
> 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 guess that something will be needed sooner or
later, also that we will implement some extensions
raher soon, but not publishing them as a valid
langugage extension.
It is great to keep the flexibility as you mentioned,
and this project will need several iterations of
many constructs. I think I should have mentioned
Extreme Programming, earlier. One necessary is
to do without lots of fixed design decisions. It
is urgent to be flexible and open to new ideas.
In the sprint, we will probably go many different
ways at the same time, and drop most of them, soon.
Our way of examinining new ways of programming
will be as extreme as the principles of extreme
programming. There is for sure no other way.
[conservative about changing language]
> 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.
You know what my goals are.
Smaller, more flexible, faster, easier to change,
easier to maintain, easier to keep backwards
compatible, more portable due to less C code,
down-sizeable by features (which is most difficult),
the full catastrophe...
> 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.
We will try to implement Python as exact and clean
as possible. The langage should be implemented
completely.
At the same time, as much as possible should become
pluggable. It will be possible to have MiniPy
without floats, without longs, without Unicode,
without generators, without bool, without enums,
it will be possible to have a Python that cannot
generate any new types and classes, and so on.
Modules which depend on these features will then not
work.
It will be a major amount of work to deduce the
dependencies of features, and how to arrange them
in a scalable shape. I do believe that the core
group will help us with that.
positively yours -- chris
Paul Rubin
> You know what my goals are.
> Smaller, more flexible, faster, easier to change,
> easier to maintain, easier to keep backwards
> compatible, more portable due to less C code,
> down-sizeable by features (which is most difficult),
> the full catastrophe...
Well ok, it wasn't clear before what the entire set of goals were.
> We will try to implement Python as exact and clean
> as possible. The langage should be implemented
> completely.
Are you going to try to keep the C API backwards compatible?
Are you going to include exact implementations of currently
not-really-documented features such as metaclasses?
Will stuff like frame objects still work as documented? Do you expect
to be able to run the current version of pdb.py without changes?
I don't think you should necessarily hold yourself to any of the
above, but that's just me.
> It will be a major amount of work to deduce the
> dependencies of features, and how to arrange them
> in a scalable shape. I do believe that the core
> group will help us with that.
I'm pretty excited by the project. I think you're going to push the
limits of the Python language harder than they've ever been pushed
against before. And you'll be in a unique position to actually remove
the limits when you hit them, rather than having to work around them.
I hope you'll trust yourself to use such opportunities when it's right
to do so.
Christian Tismer
> At 03:39 2003-01-13 +0100, Christian Tismer wrote:
> [...]
>
>>At the same time, as much as possible should become
>>pluggable. It will be possible to have MiniPy
>
>
> Is "MiniPy" the official name ?
No.
There is no official name, yet.
For some time, I was thinking of
"Lilipyt".
"Ptn" was the first thought, while
not sounding very sexy just expressing brevity.
"Pippy" is already occupied.
"Minipy"? Well, there are so many "py" projects,
this makes it hard to come up with a good new name.
While a name is most unimportant for me,
I agree that it *is* important for the
community to be able to spell it.
Anyone having some good suggestions?
Good night -- chris
Neil Schemenauer
> Anyone having some good suggestions?
Doesn't anyone know of snakes that are smaller and faster than
pythons? I think "mamba" a pretty cool name (as in black mamba).
http://animal.discovery.com/fansites/wildkingdom/blackmamba/strike/strike.html
"It is known as the fastest, longest, most aggressive and
deadliest of all venomous snakes."
Neil
Tom Bryan
> "Minipy"? Well, there are so many "py" projects,
> this makes it hard to come up with a good new name.
Start a new trend! Go for the other half of the name.
Minithon. :-)
it'll-either-start-a-trend-or-bury-the-project-in-obscurity-ly y'rs,
---Tom
Paul Rubin
> While a name is most unimportant for me,
> I agree that it *is* important for the
> community to be able to spell it.
>
> Anyone having some good suggestions?
I think you should call it PEP (for "Portability-Enhanced Python" or
something like that). Just think of the confusion that would result ;-).
Paul Rubin
> > Anyone having some good suggestions?
>
> I think you should call it PEP (for "Portability-Enhanced Python" or
> something like that). Just think of the confusion that would result ;-).
Another name I've liked is "Piton", sort of an Alpinist, high-altitude
version of Python.
Erik Max Francis
> Another name I've liked is "Piton", sort of an Alpinist, high-altitude
> version of Python.
To be completely ridiculous, name it Pitono, the Esperanto word for
_python_. Or Pitoneto, if you want to emphasize its smallness :-).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ All the gods are dead except the god of war.
\__/ Leroy Eldridge Cleaver
Bosskey.net: Aliens vs. Predator 2 / http://www.bosskey.net/avp2/
A personal guide to Aliens vs. Predator 2.
Anthony Baxter
> While a name is most unimportant for me,
> I agree that it *is* important for the
> community to be able to spell it.
>
According to
http://www.zoomschool.com/subjects/animals/Animalbabies.shtml
baby snakes are called:
Snakelet,
neonate (a newly-born snake),
hatchling (a newly-hatched snake)
More reading shows that neonates are babies that
are born "live" (not really, but it seems like it - see
http://double-d-reptiles.tripod.com/birth.html
for more), while hatchlings are from egg-laying species
(which includes Pythons).
"Snakelet" has a cool sound to it, tho...
Anthony
David LeBlanc
Patrick W
> There is no official name, yet.
>
> Anyone having some [...] suggestions?
A three letter palindrome that is both onomatapoeic (sp?) and also
connotes 'smallness':
pip. (Python in Python).
Paul Rubin
> > 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.
>
> I agree. With a real engine like an Alpha.
>
> My target physical engine is clearly the whole set of X86's which
> are dominating the world (still). I've written several small
> intepreters in C, also tried to make some fast Forth interpreter,
> and always found that the X86 doesn't have enough registers to make
> a fast, interpreted stack engine. Whenever you try to get the C
> compiler to keep your vital variables in registers, then you have
> nearly nothing left to work with. Maybe I could have optimized
> towards the primary cache, I never did this. By creating a register
> machine, I might have the chance to get the register file into that
> cache, and to have the interpreter loop variables in registers, still.
I think for the x86 you should try to generate native code rather than
an efficient interpreter. In general though, if the interpreter does
a reasonable job, IMO it's not worth trying to optimize it too much.
I'd instead concentrate more on making the compiler easy to retarget.
Btw, recent x86's have very fast L1 caches. With just a little bit of
attention to pipeline scheduling you should be able to avoid almost
all stalls.
Paul Rubin
> More reading shows that neonates are babies that are born "live"
A neonate is anything that has just been born, not necessarily a snake.
For example, a newborn human baby is a neonate.
Paul Rubin
> A three letter palindrome that is both onomatapoeic (sp?) and also
> connotes 'smallness':
>
> pip. (Python in Python).
I like this too.
Ben Wolfson
This discussion is really heading in the wrong direction. Who was the
shortest member of Monty Python?
--
I certainly seem to be enjoying myself in the same way, smacking my
lips, sighing and moaning, dripping [REDACTED] on my shirt and
smearing it into my moustache ... But ... If I snuck a lick of your
cone, I wouldn't smack my lips. -- Ted Cohen
Erik Max Francis
> A three letter palindrome that is both onomatapoeic (sp?) and also
> connotes 'smallness':
>
> pip. (Python in Python).
And please make it PIP, not PiP :-).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Nothing is so good it lasts eternally
\__/ Florence, _Chess_
Max Pandaemonium / http://www.maxpandaemonium.com/
A sampling of Max Pandameonium's music.
Erik Max Francis
> This discussion is really heading in the wrong direction. Who was the
> shortest member of Monty Python?
Now that's _really_ the wrong direction to head in. It's geeky enough
that it's named after Monty Python, isn't it?
Tim Churches
>
> Pyth.
It all depends on how much they manage to reduce the footprint of Python. If they
are really successful, it could end up being call P. Which I like.
Tim C
Afonso Fernández Nogueira
> Doesn't anyone know of snakes that are smaller and faster than
> pythons? I think "mamba" a pretty cool name (as in black mamba).
>
>
http://animal.discovery.com/fansites/wildkingdom/blackmamba/strike/strike.ht
ml
>
> "It is known as the fastest, longest, most aggressive and
> deadliest of all venomous snakes."
A beautiful name indeed. Unfortunately, it's taken by another Python project
:
http://mamba.sourceforge.net/ (an XML content manager)
cheers
fonso
holger krekel
> Bengt Richter wrote:
> > At 03:39 2003-01-13 +0100, Christian Tismer wrote:
> > [...]
> >
> >>At the same time, as much as possible should become
> >>pluggable. It will be possible to have MiniPy
> >
> > [...]
> >
> > Is "MiniPy" the official name ?
>
> No.
I suggest we use 'pypy' and/or 'Minimal Python' for
the time before the sprint.
On one of the sprint evenings we should discuss and
decide (vote) on the eventual name. [1]
Without code you can't vote :-)
cheers,
holger
[1] FWIW, Currently I think that i will propose P
(courtesy of Tim Churches).
EpSyLOn
<tis...@tismer.com> wrote:
>Bengt Richter wrote:
>> At 03:39 2003-01-13 +0100, Christian Tismer wrote:
>> [...]
>>
>>>At the same time, as much as possible should become
>>>pluggable. It will be possible to have MiniPy
>>
>> [...]
>>
>> Is "MiniPy" the official name ?
>
>No.
>There is no official name, yet.
[...]
>Anyone having some good suggestions?
I suggest TiPy/TiPython, just like "Tiny Python". And it sounds good :
Mon TiPython ;-).
--
.-. EpSyLOn sas<dot>epsylon<at>wanadoo<dot>fr
oo| faq fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
/`'\ Usenet : http://www.usenet-fr.net
(\_;/) "Quand le sage montre la lune, l'imbécile regarde le doigt"
EpSyLOn
wrote:
>On Mon, 13 Jan 2003 04:17:21 +0100, Christian Tismer
><tis...@tismer.com> wrote:
>
>>Bengt Richter wrote:
>>> At 03:39 2003-01-13 +0100, Christian Tismer wrote:
>>> [...]
>>>
>>>>At the same time, as much as possible should become
>>>>pluggable. It will be possible to have MiniPy
>>>
>>> [...]
>>>
>>> Is "MiniPy" the official name ?
>>
>>No.
>>There is no official name, yet.
>[...]
>>Anyone having some good suggestions?
>
>I suggest TiPy/TiPython, just like "Tiny Python". And it sounds good :
>Mon TiPython ;-).
Furthermore if you'd like to symbolize the fact it's written in
Python, TiPy become a recursive acronym : TiPy is (*real*) Python.
Jeremy Yallop
| While a name is most unimportant for me,
| I agree that it *is* important for the
| community to be able to spell it.
|
| Anyone having some good suggestions?
Pygmy.
P...@draigbrady.com
SnapPy
SkimPy
PepPy
ComPy (like Compile)
(I like Pygmy the best).
Pádraig.
Uly55e5
>
> Now that's _really_ the wrong direction to head in. It's geeky enough
> that it's named after Monty Python, isn't it?
>
So what about "Monty" ? In any case, snakes leave no
footprints, kind of axiomatic, so seeking a snake
with less footprint than a python is doomed to fail.
Skip Montanaro
"rattlesnake", a name I came up with a few years ago for a register-based VM
for Python (that is, "Python with more bite"). There is no "rattlesnake"
project on SF, so that's available. There's even a defunct mailing list on
Yahoo! Groups you can take over. ;-)
Skip
P...@draigbrady.com
Pynch
Pádraig.
Hans Nowak
> Bengt Richter wrote:
>
>> At 03:39 2003-01-13 +0100, Christian Tismer wrote:
>> [...]
>>
>>> At the same time, as much as possible should become
>>> pluggable. It will be possible to have MiniPy
>>
>>
>> [...]
>>
>> Is "MiniPy" the official name ?
>
>
> No.
> There is no official name, yet.
> For some time, I was thinking of
> "Lilipyt".
> "Ptn" was the first thought, while
> not sounding very sexy just expressing brevity.
> "Pippy" is already occupied.
> "Minipy"? Well, there are so many "py" projects,
> this makes it hard to come up with a good new name.
>
> While a name is most unimportant for me,
> I agree that it *is* important for the
> community to be able to spell it.
>
> Anyone having some good suggestions?
So far, most people seem to associate the idea of "minimal" as being small,
tiny... To use a different twist, what about using the minimalist movement in
art? MondrianPython, GlassPython... :-)
(Of course, being Dutch I should spell it "Mondriaan", aside...)
--
Hans (base64.decodestring('d3VybXlAZWFydGhsaW5rLm5ldA=='))
# decode for email address ;-)
The Pythonic Quarter:: http://www.awaretek.com/nowak/
Kaa:: http://www.awaretek.com/nowak/kaa.html
rzed
Oh no!! Then we'd be writing P-code!
And, at least in America, "coding in P" sounds like urine over your
head. (Not you, holger, but I mean ... )
--
rzed
John Hunter
Jeremy> Pygmy.
Nice name, so nice, it's gone. http://pygmy.sourceforge.net
How about the dimunitive:
pylet
or bare bones:
minpy
JDH
holger krekel
i guess i just forget about naming until the sprint, then :-)
holger
Carl Banks
> Erik Max Francis wrote:
>>
>> Now that's _really_ the wrong direction to head in. It's geeky enough
>> that it's named after Monty Python, isn't it?
>
> So what about "Monty" ?
Then we can refer to CPython as the Full Monty. Har har har.
--
CARL BANKS
Carl Banks
> Anyone having some good suggestions?
Python 3K
--
CARL BANKS
Kow K
>
> Jeremy> Pygmy.
>
> Nice name, so nice, it's gone. http://pygmy.sourceforge.net
Damn ... but adding a twist, how about this?
Pygmon
Also, this is the name of a small, human-friendly monster featured in a
Japanese TV movies series in 60's. It was a blend of Pygmy + monster,
but it looks like Python, too. You can see how it looks like in the
following page:
http://www.waynebrain.com/ultra/episodes/man/3739_man.html
Cheers,
Kow
Christian Tismer
Paul Rubin wrote:
> Christian Tismer <tis...@tismer.com> writes:
>
>>You know what my goals are.
>>Smaller, more flexible, faster, easier to change,
>>easier to maintain, easier to keep backwards
>>compatible, more portable due to less C code,
>>down-sizeable by features (which is most difficult),
>>the full catastrophe...
>
>
> Well ok, it wasn't clear before what the entire set of goals were.
>
>
>>We will try to implement Python as exact and clean
>>as possible. The langage should be implemented
>>completely.
Now Paul is nailing thing down :-)
> Are you going to try to keep the C API backwards compatible?
I wish to, but I cant guarantee it. This is
a matter of experimentation. Fore sure, we
will try to build a version that adheres to
the C API, at least in the early bootstrap
phase, we really need to do so, in order to use
"borrowed" internals and extensions.
It then depends on experience to be gathered,
how much conformance to the C API costs. If it turns
out to be much more efficient to use a different
API, and maybe a radical change of internal
data structures as well, then TiPy (randomly picked
name from all the proposals :) is the first chance
to try such new ways at all.
This can lead to a compatibility layer (maybe hard
to implement), and these insights may become
proposals to change core Python as well.
It is also thinkable to have options in TiPy which
make even this configurable at boot time, and people
can decide whether they want it compatible or faster.
Some of the "internal" API like compiler related
functions and stuff from ceval.c will most probably
be changed, anyway, but the common API will be
as it is now. This is where we start with.
> Are you going to include exact implementations of currently
> not-really-documented features such as metaclasses?
Absolutely. I'm using metaclasses very much, and I
also will chime a compatible patch in, which allows
to use slots in metaclasses. I need that, and Stackless
has it.
> Will stuff like frame objects still work as documented? Do you expect
> to be able to run the current version of pdb.py without changes?
Yes, for the first round, frames should be rather
like they are now. They will get more interfaces
to be manipulated by Python code.
pdb.py should run as it is now.
I know there is an issue with Psyco, which doesn't
create frames all the time. This is an issue that
need thorough discussion and design.
> I don't think you should necessarily hold yourself to any of the
> above, but that's just me.
If the above can be achieved for a reasonable
price, then we really should try. If it hurts
too much, then it may be easier to change the
rest of the world :-)
>>It will be a major amount of work to deduce the
>>dependencies of features, and how to arrange them
>>in a scalable shape. I do believe that the core
>>group will help us with that.
>
>
> I'm pretty excited by the project. I think you're going to push the
> limits of the Python language harder than they've ever been pushed
> against before. And you'll be in a unique position to actually remove
> the limits when you hit them, rather than having to work around them.
> I hope you'll trust yourself to use such opportunities when it's right
> to do so.
Thanks for the encouragement. I hope to to as
well as possible. Not loosing chances to stay
compatible, at the same time not loosing good
new opportunities by sticking too much with
old principles.
This is not easy and a balancing act. Something
that I could not do alone, and I'm happy that
there are so many supporters and people going to
help.
I'd-love-to-have-*you*-in-that-group-too -- chris
--
Christian Tismer :^) <mailto:tis...@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/
Manuel M. Garcia
possible, even if performance is below that of CPython.
Because imagine a crude version is quickly released that runs 50 times
slower than CPython (and *nobody* expects performance this bad). It
will have fast context switching between threads (thanks to Christian
begin on the team ;-) ), so even if a "first playable" is this slow,
it will still be faster than CPython for an interesting set of
applications. Maybe because it is feasable to customize the context
switching for the specific application (because it is just Python
code, after all), it will run at a pretty good clip!
Secondly, the pool of programmers willing to write finely-tuned code
will be pretty large, considering development will be in Python and
not it C. I can imagine many Python programmers will love to work
man-years on this, even to the point of harming marriages!
Also, please allow "thread pickling" from day one. (I remember
Christian saying Stackless 1.0 had thread pickling.)
Actually, thread pickling might give a performance boost. I was
thinking about it during the weekend; you code a loop in a thread,
take it through its paces through test data, all the while <PyPy> is
figuring out how to make things run fast. Then when you get the
performance you want, you just pickle the thread, and all the
performance "hacks" get pickled. When you unpickle the thread in the
deliverable, it zips along immediately, without the "inspection" time
you would expect from the PSYCO technique.
It is hard *not* to be excited about this project!
Manuel
Gareth McCaughan
> IIRC the etymology of Scheme-48 is that 48 is 84 spelled backwards--it
> was supposed to be a simple implementation of Scheme-84.
The explanation given by its creators is that it was supposed
to be so clean, well-organized and simple an implementation
that one could understand it completely in 48 hours. They
admit that this objective has not been completely achieved :-).
Of course it's possible that there are other reasons for the
name; perhaps the official one is retrofitted.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Christian Tismer
> pythons? I think "mamba" a pretty cool name (as in black mamba).
>
> http://animal.discovery.com/fansites/wildkingdom/blackmamba/strike/strike.html
>
> "It is known as the fastest, longest, most aggressive and
> deadliest of all venomous snakes."
I'm frightened!
Brrr. Do you really think this project deserves
such an agressive name?
probably, yes, given that you join it -- chris
Christian Tismer
> Pyth.
Sounds a bit like the winds after digesting Chili Con Carne :-)
Christian Tismer
...
> [1] FWIW, Currently I think that i will propose P
> (courtesy of Tim Churches).
Ys t s shrt.
c - c
Christian Tismer
> holger krekel wrote:
>
>>[Christian Tismer Mon, Jan 13, 2003 at 04:17:21AM +0100]
>>
>>>Bengt Richter wrote:
>>>
>>>>At 03:39 2003-01-13 +0100, Christian Tismer wrote:
>>>>[...]
>>>>
>>>>
>>>>>At the same time, as much as possible should become
>>>>>pluggable. It will be possible to have MiniPy
>>>>
>>>>[...]
>>>>
>>>>Is "MiniPy" the official name ?
>>>
>>>No.
>>>There is no official name, yet.
>>
>>I suggest we use 'pypy' and/or 'Minimal Python' for
>>the time before the sprint.
>>
>>On one of the sprint evenings we should discuss and
>>decide (vote) on the eventual name. [1]
>>
>>Without code you can't vote :-)
>>
>>cheers,
>>
>> holger
>>
>>
>>[1] FWIW, Currently I think that i will propose P
>> (courtesy of Tim Churches).
>
>
> Oh no!! Then we'd be writing P-code!
Ha haaaaa, yes, this is really an argument.
No, I won't write P-code again any time of my life.
> And, at least in America, "coding in P" sounds like urine over your
> head. (Not you, holger, but I mean ... )
Pay attention, he's peeing code.
Thanks, I'm convinced. It is *not* P.
ciao - chris
Christian Tismer
Hee hee. Rattlesnake!
I know about a couple of people from Texas,
who told me "we don't negotiate with rattlesnakes".
So they will probably shoot me if we don't come
up with a reasonable development.
Maybe we should exercise some coding, before we
can judge whether it is really going to rattle? :-)
your's sincerely -- chris
Christian Tismer
Yeah!
Pyg me too please :-)
David LeBlanc
David LeBlanc
Seattle, WA USA
David LeBlanc
David LeBlanc
Seattle, WA USA
> -----Original Message-----
> From: Christian Tismer [mailto:tis...@tismer.com]
> Sent: Monday, January 13, 2003 15:50
> To: David LeBlanc
> Cc: pytho...@python.org
> Subject: Re: Seeking Minimal Python Project Name (was: [pypy-dev] Re:
> [ann] Minimal Python project)
>
>
Christian Tismer
> Christian Tismer wrote:
>
>>Anyone having some good suggestions?
>
>
> Python 3K
Pssssst!
Where did you get the the machine from!
Erik Max Francis
> Pynch
I was actually considering this name for my template system which
eventually became known as EmPy, but it's already taken by a Python
color editor:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/pynche/
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Describe a circle, stroke its back and it turns vicious.
\__/ Ionesco
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Terry Hancock
> While I am gripped in fear at the thought of Python spinning into a
> series of downward spiraling dialects...
> The adventurer in me says, "Give'em hell boys... Damn the
> torpedoes..."
Well, a new implementation is not a new dialect. This is probably going to
be no more different from C Python than Jython is. Both interpret Python
code, which is pretty much what I require. Of course, it will affect
Python + C packages, in that they won't be portable to it in general.
Of course if they were to acheive their performance goals, it might become
the main implementation.
Me, I'm just going to keep writing Python apps, and hope they're portable.
Rewriting compilers is out of my league. Brave Python rewriters, I salute
you. ;-)
Cheers,
Terry
--
Anansi Spaceworks
http://www.anansispaceworks.com
Terry Hancock
> Thanks, I'm convinced. It is *not* P.
Hey, that sounds cool: "notP". I like it.
Paul Rubin
> The explanation given by its creators is that it was supposed
> to be so clean, well-organized and simple an implementation
> that one could understand it completely in 48 hours. They
> admit that this objective has not been completely achieved :-).
> Of course it's possible that there are other reasons for the
> name; perhaps the official one is retrofitted.
Hmm, there's a much simpler Scheme implementation by George Carrette
called "siod", which at one point stood for "Scheme in One Day"
(referring to the implementation time he thought would be needed).
I probably spent a day or so looking at the T code. That's certainly
not enough to understand it completely, but it was enough to see the
outline and at numerous times find myself saying "hey, cool, wow", etc.