Guido van Rossum wrote:
[snipped all what's addressed to Tim]
> All this is possible by the introduction of an explicit generator
> object. I think Tim had an implementation in mind where the standard
> return pointer in the frame is the only thing necessary; actually, I
> think the return pointer is stored in the calling frame, not in the
> called frame (Christian? Is this so in your version?). That
> shouldn't make a difference, except that it's not clear to me how to
> reference the frame (in the explicitly coded version, which has to
> exist at least at the bytecode level).
No, it isn't. It is still as it was. I didn't change the frame
machinery at all. The callee finds his caller in its f_back field.
[...]
> (I'm still baffled by continuations. The question whether the for
> saved and restored loop should find itself in the 1st or 5th iteration
> surprises me. Doesn't this cleanly map into some Scheme code that
> tells us what to do? Or is it unclear because Scheme does all loops
> through recursion? I presume that if you save the continuation of the
> 1st iteration and restore it in the 5th, you'd find yourself in the
> back 1st iteration? But this is another thread.)
In Scheme, Python's for-loop would be a tail-recursive expression,
it would especially be its own extra lambda. Doesn't fit. Tim is
right when he says that Python isn't Scheme.
Yesterday I built your suggested change to for-loops, and it works
fine. By turning the loop counter into a mutable object, every
reference to it shares the current value, and it behaves like
Tim pointed out it should.
About Tims reply to this post:
[Gui-do]
> The generator machinery would (ab)use the fact that Python frames
> don't necessarily have to be linked in a strict stack order;
[Tim-bot]
If you call *this* abuse, what words remain to vilify what Christian is
doing <wink>?
As a matter of fact, I have been thinking quite long about
this *abuse*. At the moment I do not do this. The frame stack
becomes a frame tree, and you can jump like Tarzan from leaf to
leaf, but I never change the order. Perhaps this can make
sense too, but this is curently where *my* brain explodes.
Right now I'm happy that there is *always* a view of the top
level, and an exception always knows where to wind up.
Form that point of view, I'm even more conservative than Guido
(above) and Sam (replacing whole frame chains).
In a sense, since I don't change the frame chain but only
change the current frame, this is like a functional way to
use weak references.
The continuation approach is to build new paths in a tree,
and loose those which are unreachable. Modifying the tree
is not part of my model at the moment. This may be
interesting to study after we know everything about this tree
and wee need even more freedom.
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
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