Implementing BREAK, CONTINUE

[stonier]

I fancy these would be quite useful. At least, I went looking to use something like this, found these unimplemented markers and had quite optimistic hopes dashed when I noticed:

// TODO: Handle BREAK or CONTINUE?

What would it entail? It looks like we'd probably have to recompute the stack from the adjacency list with instructions to skip a marked vertex. Right now, haven't drilled so far down to know how difficult this might be.

[stonier]

Hrm, maybe easier. Get a subgraph from the current vertex. Then parse each vertex in the subgraph and remove it from the remaining items in the currently computed stack if it is found there.

[v4hn]

I'm not really sure how these two different results should be handled and how they differ.
Given that QUIT already terminates the overall execution of the plasm,
I would expect that on BREAK the current iteration through the plasm is aborted
and execute resets the stack counter and continues with the next iteration of the plasm.
Actually, this is a behavior I miss in ecto quite a bit.
Is this behavior reasonable/intended? If so, I would be happy to contribute a patch for the BREAK return code.

[stonier]

I do not know what the original authors intended - what is there right now seems like a stub for some original design plan.

Your proposal seems reasonable. Send a pull request and we can iterate on it there.

@vrabaud any thoughts?

[stonier]

For the purposes of clarity, I think we can define here:

• BREAK - abort current graph execution, but if multiple executions have been scheduled, proceed with the next one immediately.
• CONTINUE - abort the current cell and its subgraph, but otherwise continue with the current execution.