Hi all, Re "continuation": I'm sorry for all the confusion. I should have called these objects what they really are in C, i.e. 'frame_stack_top' objects. Not more, not less.
This is the wrong level for language design! It's just a quick hack to expose some of the capabilities of the generated C code to RPython. No one should actually *use* these things at RPython level. They are meant to build mixedmodules on top of, and these mixedmodules should expose saner and carefully designed concepts to app-level, like Tasklets, greenlets, green threads, etc. The real hard work is in building such mixedmodules. Anyway I'm sure that while doing so we will pretty soon figure out that slightly or completely different things should be exposed from C to RPython. If you want a comparison, see pypy.rpython.ros.environ(idx) -> string. It's a bizarre interface to get to the current environment from RPython: you have to call it with increasing numbers until it returns None to mean "there is no more environment variable". It's only done this way because it's straightforward to translate such a function to C. But of course it's only used by pypy.module.posix to expose the more usual interface to app-level, via the 'os' module, and no one else should rely on this strange RPython-level interface. A bientot, Armin. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
