Bob Rogers wrote:
Almost two weeks ago, I had what I thought was a clever idea for
eliminating the continuation barrier from action invocation: Simply
call the action using the original continuation instead of creating a
new RetContinuation. The original continuation, I reasoned, should be
re-entrant after having the dynamic environment partially restored.
Unfortunately, it's not that easy. The trick is that you need to
pass values from the original context, not the one that is exiting. And
exception handling is, well, exceptional: The values come from C code,
and not any context. So I had to add a 'payload' slot to struct
Parrot_cont in order to remember the exception; I had been hoping to
avoid extra state. Furthermore, there is no way for the vtable method
of a superclass to abandon the rest of the subclass method, so I used
some flag-setting kludgery to hack around that [1].
I can see why the solution was tempting, and I'm glad you tried it out.
I can also see why you paused to ask if it was worth continuing. Your
instincts are right, this solution gradually pushes further and further
from where we want to be.
Out of the possible hacks we could do, I'd rather go for the hack of
providing a way to create a new RetContinuation from within the C code
(even if it's a special kind of return continuation with the same
interface, but a different set of internal actions to satisfy the
interface).
[1] I also merged Error_Handler:invoke into Continuation:invoke; it
actually reduces the code volume, but flattens the abstraction,
which doesn't feel quite right. But the point of the existing
Error_Handler:invoke is to return values from C, which ought to be
handled generally anyway. And I assume EH can go away after PDD23,
replaced with a general Continuation. In fact, it may even be
possible to get rid of it now.
Can you make this a separate patch, so we can review it independently?
I'm not sure we want to do it, but it's worth considering, on the
"Distinction vs. Reuse" design scale.
Allison
