In SLIME, every low-level opeator is actually a method call in the responder interface of the lowlevel module. For slime, the SMOP__SLIME__Operators type is actually also a responder interface that handles special methods. Calling it from the low-level works the same as calling from the high level. Every operation message is composed by basically three elements:

• 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 from a known lowlevel type, so when building a lowlevel call in the high-level these specialized objects must be created and not regular capture objects.

In order to actually being able to call the operators, the low-level defines some constant objects that will later stringify to the operation name. When in the high-level using them or their stringification is valid, but using the constant values is an optimization as it will result in simple pointer comparisions instead of unicode string comparision.

The first challenge on that, is the fact that Capture is also an object, and then you might ask how as we going to create an object if we need an object to create it. And that's where a mix between frame population time and runtime comes to rescue.

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__Stack and the SMOP__SLIME__Node prototypes are the ones used to create new frames and to operate on it. Differently from the lowlevel stack operations that manipulate the currently running stack, these methods are safe to be run without a current stack at all. This methods always look for the stack as the invocant in the capture, and not as the stack 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 stack. 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 Stack prototype. This method will actually call a message using the given stack as the call stack, and probably cause stack manipulation. The methods of this types already use a high-level compatible Capture (as opposed to the lowlevel stack operators that use a different object as the capture), but still some helper C methods are defined here to create the captures, as to make it possible to use these methods from the low-level more easily and efficiently. As with the lowlevel operators, a set of constants is defined as to provide a more optimized method for name resolution for this prototypes. But if that fails, it will fallback to string name resolution.

Both SMOP__SLIME__Frame and SMOP__SLIME__Node are closed and final.

SMOP__SLIME__Operators

As this includes low-level C calls, I'll keep the docs in the header file. Please check include/smop_slime.h.

• forget: drop the past nodes of this frame for eager garbage collection
• move_capturize: create a new capture from the result of past nodes
• move_identifier: set the identifier from the result of a past node
• move_responder: set the responder from the result of a past node
• copy: create a copy of the result of a past node

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: $node) -- sets the node as the currently selected node.
• eval($frame: ) -- evaluates the currently selected node and stores the result in the result field of the 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.
• push($frame: ) -- implements subroutine-call-like semantics passing the current capture as the result of the first 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

and the following methods:

• new($proto: :$.responder, :$.identifier, :$.capture, :$.debug, :$.jail, :$.result) -- creates a new node
• accessor methods like responder($node: $newvalue?)