* responder: which responder interface handles this message
* identifier: the identifier for the message
* capture: the arguments to this message

This is valid from bottom up. This way, it's important to make available some identifiers for this operations. The only difference from the lowlevel operations to the high-level is that on the low-level the capture object must be the native type.

Let's consider you want to build a frame in the runtime, then you'll need to capture the parameters to the frame operations. You do that by knowing the frame you are creating, and then moving things in the frame to make them available to other calls. As the knowledge of what to move, from where and to where is already available when you are building the frame you'll invoke, you can use at that time some specific objects and build the frame. This specifc objects don't use the SMOP frame, only the C stack which makes you free to call them anytime, by using the lowlevel C subroutine, while the prototype will still support a high-level call that builds the same object.

The SMOP__SLIME__Frame and the SMOP__SLIME__Node prototypes are the ones used to create new frames and to operate on it. This methods are safe to be run without a current interpreter, they always look for the frame as the invocant in the capture, and not as the interpreter parameter to the lowlevel MESSAGE call. In fact, when calling the low-level MESSAGE (using SMOP_DISPATCH, probably) you can even pass NULL as the current interpreter. IF this methods need to recurse they will do it using the C stack. The only exception for this rule is the "eval" method on the Node prototype. This method will actually call a message using the given interpreter as the call stack, and probably cause frame manipulation.

Both SMOP__SLIME__Frame and SMOP__SLIME__Node are closed and final.

^ SMOP__SLIME__CurrentFrame

CurrentFrame is a pseudo-prototype-responder-interface that delegates any call to the current frame passing it as the invocant of the message.

^ SMOP__SLIME__Frame

The frame object represents a set of nodes plus lexical and backtrace information. It has the following members:

* $.lexical: the lexical information for this frame
* $.back: the continuation that precedes this one
* $!nodes: the list of nodes
* $!node_count: the count of nodes
* $!pc: the program counter on this frame.

and the following methods:

* new($proto: *@nodes, :$.lexical, :$.back) -- Creates a new frame with the given node and the given lexical and back information
* next($frame: ) -- goes to the next node in the frame, possibly drop it for the back.
* goto($frame: $count) -- sets the current node as $count nodes before or after the current one.
* eval($frame: ) -- delegates to eval on current node.
* result($frame: $count) -- gets the result of the past node that is $count away from the current node.
* has_next($frame: ) -- returns true if there's any more node to eval.
* setr($frame: $value) -- sets the result of the current node to the given value.
* drop($frame: ) -- implements return-like semantics, calling setr last return and goto back.
* forget($frame: ): drop the past nodes of this frame for eager garbage collection
* move_capturize($frame: $caturize_obj, $target): create a new capture from the result of past nodes
* move_identifier($frame: $source, $target): set the identifier from the result of a previously ex node
* move_responder($frame: $source, $target): set the responder from the result of a past node
* copy($frame: $source, $target): create a copy of the result of a past node
* jail($frame: ): delegates to the current node
* debug($frame: ): delegates to the current node

^ SMOP__SLIME__Node

The node object represents an instruction in this frame. It has the following members:

* $.responder: The responder interface for this call
* $.identifier: The identifier for this call
* $.capture: The capture for this call
* $.debug: Debug information
* $.jail: Information for exception-like behaviour
* $.result: Result of the evaluation of this node

This object is the mandatory native type for the "move_capturize" method on the Frame. It contains low-level information of which nodes to look for results in order to build a new capture object. The following low-level C calls are available: