Default SMOP Interpreter Implementation: Revision 12
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:
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.
As this includes low-level C calls, I'll keep the docs in the header file. Please check include/smop_slime.h. This methods actually delegate to the frame.
The frame object represents a set of nodes plus lexical and backtrace information. It has the following members:
and the following methods:
The node object represents an instruction in this frame. It has the following members:
and the following methods: