Design Policy for Dynamic Lane Materialization Using OVER_LAYER

 

Design Policy for Dynamic Lane Materialization Using OVER_LAYER

In this design, lanes are not defined as fixed entities that require separate management. The existence of a lane is represented simply by its presence as a member of the lane array. Therefore, no lane master table, existence flag, enabled state, or dedicated management ID is introduced.

OVER_LAYER serves as the central table for describing the internal structure of each lane after the lane itself has been established. Each row represents the lane to which a layer belongs, the identity of that layer, the label it exposes, the number of repetitions, and its position within the nesting structure. In the current design, rows belonging to the same lane are arranged from the innermost layer to the outermost layer, and the row order itself forms part of the structural information.

Lanes are not constructed and fixed in advance during program generation. Instead, when a trampoline execution request occurs, the rows belonging to the requested lane are dynamically extracted from OVER_LAYER. The extracted layers are then gathered, attached to one another, and assembled from the inside outward according to their defined order. Through this process, structural definitions that were distributed across the table become an executable lane reflecting the state of OVER_LAYER at that moment.

In this design, the entire process is called Materialize.

Materialize does not merely mean searching for a lane or invoking an existing function. It refers to the complete process of extracting the relevant structure from OVER_LAYER, gathering the associated layers, forming their nested structure, and turning them into an executable entity that can operate on the trampoline.

The conceptual flow is as follows:

Specify the target lane
        ↓
Extract the corresponding rows from OVER_LAYER
        ↓
Gather the extracted rows in layer order
        ↓
Assemble the nested lane structure
        ↓
Form the initial trampoline instruction
        ↓
Execute

Source code supplied externally is not subdivided and encoded inside OVER_LAYER. OVER_LAYER describes structure, not processing logic. External code remains separate and is connected to lanes or execution phases as processing content. This keeps structural definition independent from implementation logic.

The responsibilities of the main components are defined as follows:

Lane array
= the collection of available execution paths

OVER_LAYER
= the internal structures layered onto those paths after their creation

External source
= the processing logic executed while passing through the structure

Materialize
= the process of extracting and gathering the target structure
  and turning it into an executable lane

Trampoline
= the execution mechanism that continuously runs
  the materialized lane through continuations

PAYLOAD
= shared state carried across lanes and execution phases

In a design where all lanes are constructed and stored in advance, OVER_LAYER becomes a static configuration read only during initialization. In the present design, only the requested lane is extracted and assembled at execution time. As a result, OVER_LAYER functions as an internal design blueprint that remains active during runtime.

The current implementation already extracts rows by lane and nests them in row order to form lane programs. The proposed concept therefore does not replace the existing structural model. Instead, it shifts the timing of construction from initialization to the moment of execution.

The central concern of this design is not the management of lanes themselves. It is the process by which the structures described in OVER_LAYER gather around the requested lane and emerge as an executable form at the moment they are needed.

The fundamental principle of the design can therefore be summarized as follows:

A lane exists as a member of the lane array, while OVER_LAYER retains the internal structures added afterward. At execution time, the target structure is dynamically extracted and gathered, materialized into a functioning lane, and then run on the trampoline.