Because of the way that SMOP OO Bootstrap, it's important to have a very precise definition of its boot process, in order to make sure that no call using values that weren't yet defined occour, since this would probably cause a segfault.

Kernel Loading

SMOP Constant Identifiers

The constant identifiers, as its Responder Interface, use a very simplistic code to start. It uses plain libc calloc calls to initialize it, with static methods. Before the boot finishes, it is not allowed to call any method on a constant identifier. The correct way of matching a constant identifier during boot is by checking for pointer equity. This values are not subject to garbage collection.

SMOP Lowlevel

The smop lowlevel implements the basic default memory management mechanism of SMOP. Most of the objects will depend on it.

SMOP Interpreter Instance Prototype

The prototype of the interpreter instance is the one that will enable evaluating any code. There will be no way of calling anyting in it untill the capture object is booted. But as the interpreter prototype doesn't depend on the lowlevel, it's initialized here, specially because there's a constant capture that uses this pointer.

SMOP Native Types: capture

As every call, from bottom-up, is compatible with the high-level runtime. Every call need a capture object, this way, the capture native type is a key to bootstrap. There are native C methods to create and access the capture from C, as well as there will be high-level methods to do it too.

SMOP Native Types: int

The capture type defines positional access, as the default smop interpreter implementation have operators that depends on ints. That's why int needs to be initialized here.

SMOP Native Types: bool

The capture type defines positional access, as the default smop interpreter implementation have operators that depends on ints. That's why int needs to be initialized here.

Default SMOP Interpreter Implementation

At this point we already have everything needed to initialize the smop_stack objects. They need to be initialized soon as the lowlevel object destruction depends on it.

Init

At this point, we have a somewhat complete environment, then are then in the safer phase of the boot.

SMOP Native Types

The rest of the SMOP native types should be initialized.

SMOP Builtin Types

Here the bultin types should be initialized.

Global Namespace

The global namespace should be created, and the types registered in it.

What happens after that?

Well, at that time, the smop library will hand control to the executing program, no real executable was planned yet. Everything is now in terms of the test cases only. Maybe embedding in Perl 5 using OP customization is a nice start idea.