SMOP Inter Continuation Communication

The way SMOP is designed allows a feature called Polymorphic Eval. This feature basically means that different interpreter executions can be part of the same run loop, by using Continuation Passing Style. The challenge here is how to send information from one continuation to the other, considering that the only thing known about each continuation is the API.

For instance, let's consider during an execution of some code in the perl5 stack, a method in the smop default interpreter implementation must be called with some parameters, and that the return of this should be returned to the perl5 stack like in the diagram below:

  p5 -> p5 -> p5 -> entersub  -  -   -   -   -   - > p5 -> p5
                       |                        ^
                       V                        |
                      smop -> smop -> smop -> smop

As I said before, this interposition won't be made in terms of a stack, but in tems of CPS. This means that before calling goto on the interpreter to switch to smop, the entersub needs to send the parameters to the smop, the same way that smop needs to send the result to p5.

On the other hand, in some cases, the interception in the interpreter must not change any information in the original execution, for instance, for a warning call.

 foo -> foo -> (something that generates a warning) -> foo -> foo
                 |                              ^
                 V                              |
                warning -> code -> being -> executed

And the original execution shouldn't even realise that it was interrupted. The exact same pattern should map a OS interruption callback.

 foo -> foo -> foo  ... ... ... ... ... ... ... ... -> foo -> foo
                 |                              ^
                 V                              |
            interrupt -> handler -> being -> executed

This kind of behaviour can be achieved by using two methods in the interpreter API:

The goto method does what it says, switches the interpreter's context to the given continuation. The setr method, on the other hand, delegates to the implementation a signal that the "result" of the "current point of execution evaluation" should be the given value. This is how return values must be implemented, and how parameters passing must be implemented also, considering that because of the run loop design, the first node won't be evaluated.