Jeremy Hylton wrote:
I think it makes sense to avoid being obscure or unclear in order to minimize the size of the patch or the diff. Realistically, it's unlikely that anything like your original patch is going to make it into the CVS tree. It's primary value is as proof of concept and as code that the rest of us can try out. If you make large changes, but they are clearer, you'll help us out a lot.
Many many thanks. This is good advice. I will make absolutely clear what's going on, keep parts untouched as possible, cut out parts which must change, and I will not look into speed too much. Better have a function call more and a bit less optimization, but a clear and rock-solid introduction of a concept.
We can worry about minimizing the impact of the changes on the codebase after, after everyone has figured out what's going on and agree that its worth doing.
feeling-much-more-confident-because-I-didn't-say-continuation-ly yr's, Jeremy
Hihi - the new little slot with local variables of the interpreter happens to have the name "continuation". Maybe I'd better rename it to "activation record"?. Now, there is no longer a recoursive call. Instead, a frame object is returned, which is waiting to be activated by a dispatcher. Some more ideas are popping up. Right now, only the recursive calls can vanish. Callbacks from C code which is called by the interpreter whcih is called by... is still a problem. But it might perhaps vanish completely. We have to see how much the cost is. But if I can manage to let the interpreter duck and cover also on every call to a builtin? The interpreter again returns to the dispatcher which then calls the builtin. Well, if that builtin happens to call to the interpreter again, it will be a dispatcher again. The machine stack grows a little, but since everything is saved in the frames, these stacks are no longer related. This means, the principle works with existing extension modules, since interpreter-world and C-stack world are decoupled. To avoid stack growth, of course a number of builtins would be better changed, but it is no must in the first place. execfile for instance is a candidate which needn't call the interpreter. It could equally parse the file, generate the code object, build a frame and just return it. This is what the dispatcher likes: returned frames are put on the chain and fired. waah, my bus - running - ciao - chris -- Christian Tismer :^) <mailto:tismer@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