Guido van Rossum wrote:
>
> Tim wrote:
>
> > Sorry, Chris! Just a case of "no time" here. Of *course* you
> > should continue, and Guido should pop in with an encouraging word
> > too -- or a "forget it". I think this design opens the doors to a
> > world of interesting ideas, but that's based on informed prejudice
> > rather than careful study of your code. Cheer up: if everyone
> > thought you were a lame ass, we all would have studied your code
> > intensely by now <wink>.
>
> No time here either...
>
> I did try to have a quick peek and my first impression is that it's
> *very* tricky code! You know what I think of that...
Thanks for looking into it, thanks for saying it's tricky.
Since I failed to supply proper documentation yet, this
impression must come up.
But it is really not true. The code is not tricky
but just straightforward and consequent, after one has understood
what it means to work without a stack, under the precondition
to avoid too much changes. I didn't want to rewrite
the world, and I just added the tiny missing bits.
I will write up my documentation now, and you will
understand what the difficulties were. These will not
vanish, "stackless" is a brainteaser. My problem was not how
to change the code, but finally it was how to change
my brain. Now everything is just obvious.
> Here's what I think we should do first (I've mentioned this before but
> nobody cheered me on :-). I'd like to see this as the basis for 1.6.
>
> We should structurally split the Python Virtual Machine and related
> code up into different parts -- both at the source code level and at
> the runtime level. The core PVM becomes a replaceable component, and
> so do a few other parts like the parser, the bytecode compiler, the
> import code, and the interactive read-eval-print loop. Most object
> implementations are shared between all -- or at least the interfaces
> are interchangeable. Clearly, a few object types are specific to one
> or another PVM (e.g. frames). The collection of builtins is also a
> separate component (though some builtins may again be specific to a
> PVM -- details, details!).
Good idea, and a lot of work.
Having different frames for different PVM's was too much for
me. Instead, I tried to adjust frames in a way where a lot
of machines can work with.
I tried to show the concept of having different VM's by
implementing a stackless map. Stackless map is a very tiny one
which uses frames again (and yes, this was really hacked).
Well, different frame flavors would make sense, perhaps.
But I have a central routine which handles all calls to frames,
and this is what I think is needed. I already *have*
pluggable interpreters here, since a function can produce
a frame which is bound to an interpreter, and push it
to the frame stack.
> The goal of course, is to create a market for 3rd party components
> here, e.g. Chris' flat PVM, or Skip's bytecode optimizer, or Greg's
> importer, and so on.
I'm with that component goal, of course. Much work,
not for one persone, but great.
While I don't think it makes sense to make a flat PVM
pluggable. I would start with a flat PVM, since that opens
a world of possibilities. You can hardly plug flatness in
after you started with a wrong stack layout. Vice versa,
plugging the old machine would be possible.
later - chris
--
Christian Tismer :^) <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4