Bob Rogers wrote:
We're going to a completely stackless virtual machine. But Parrot is already stackless. The dynamic_env slot to which I assume you refer is really a tree with upward pointers.
To be clear, Parrot will have no *global* stack. The data structure implementing the stack isn't the problem, the global nature of it is.
And, how are you implementing those using 'pushaction'? Was [1] not detailed enough? This message links to [2] (from my YAPC talk), which has working examples (up until the merge at least). If you need more detail, please be specific, though it will probably have to wait until after the Parrot release.
I need code examples. Show me samples of the PIR code you're generating that used 'pushaction'. Try to include the smallest amount of code possible, so we can go straight to "this is how I'm implementing feature X".
It sounds like you're trying to tell me that I should not be using continuations to implement *any* sort of nonlocal control flow. If so, it would have been kinder to say so before I put my time into a YAPC talk where that was the central theme.
No, you should definitely use continuations. What you shouldn't use is the dynamic_env stack. And, I'll happily walk you through moving away from the dynamic_env stack and onto the new system. (I know it's different, which causes initial frustration, but it's much better.)
They can effectively implement the same features as 'pushaction', but in a safer, continuation-friendly, non-global way. You've completely lost me. Not only do they have to be global (for some definition of "global"), as far as I was concernced they had been "safe" and "continuation-friendly" until the pdd25cx merge.
No, it wasn't. The old code tied the continuation-based control flow to the stack, requiring that the Continuation PMC's 'invoke' do all the work of both a CPS virtual machine *and* a stack-based virtual machine. As a result, we couldn't run continuations across the C barrier. As a result we were getting numerous inexplicable segfaults and exceptions from obscure control-flow bugs. Essentially, the old code was largely responsible for the "inferior runloop" problem we've been tearing our hair out about for over a year. It had to go.
At a minimum, I need to be able to return values.
Yes, certainly. That's no problem.
But wait a minute: Aren't these features documented somewhere? If so, please point me there, and maybe I can figure out what I need on my own. If not, why not?
The control actions? No. Because they're brand-new. Currently they're only used by exceptions, but it sounds like Patrick will need them for Perl 6. They will also be used by variants of local-branch and local-return that don't accept a user-defined array object (but, those variants aren't implemented yet).
Allison
