the node stack

[viperscape]

It's not apparent what has been stacked and what has completed once many nodes have intertwined. This needs to be resolved. While next:clear offers a way to kill off the stack, it's too much to think about. A good example of this is the mystic example story I'm building up. Once tavern-enter heads to the tavern node, it's not apparent that eventually tavern-enter will be continued on. This is problematic. Originally lichen would drop the node once a next was called on; however, I also wanted to call upon nodes as if they were functional, to write side-effects. I think it might be best to use new syntax to differentiate between the two. One type being just side-effect calls. Problematically, this means decision based calls like having a drink will have similar syntax and really make the backend logic convoluted.

It might be best to instead not have a node-stack in this regard, and rely on next:back command logic

[viperscape]

After thinking on this, I think removing the stack entirely is in order. Originally I used the stack concept into the evaluator because I wanted nodes to be able to be traversed and fall back on the previous node. This is too vague in actual use. Instead I think lichen should drop the next:back and have a next:call for a callback node.

This means that when a next target is successfully called on, the current node source position should be cleared out, so the evaluator should only track one node at a time. Clearing out the node's source position would be done with the advance method of the evaluator. The only tracking that then will need to be done is with the callback node-- so it can call back to the originating node. This will need to be a stack, so calls can be chained.

[viperscape]

This is basically fixed with the exception that it's impossible to perform a call action within a select, and the necessary syntax would look aweful I think. This will have to sit on the back burner until needed