R3 Delayed Modules

A proposed method of delaying when a module is actually constructed.
Updated: 12-Mar-2024 (F5 to be sure)

Purpose

It's useful to have the capability to add a module name and spec to the module list, but without the module being initialized. Essentially, the module is cataloged. The main benefits are:

1. Memory and startup time are reduced because only a shallow load is required to gain access to the module's header.
2. Programs can inspect the list of what modules are available, along with their titles, versions, options and other info.
3. A program can import the module at a later time when it needs it.

This mechanism also provides greater flexibility to hosted extensions, because only the extensions that are needed will actually be loaded. For example, the various extensions associated with graphics may be fairly large (in REBOL magnitude/scale) but they don't need to be loaded or bound.

Example

Here's an example. A developer compiles an R3 exe that includes a host with ten embedded extension modules. However, let's say a user only wants one of the extensions. During boot, all of the extensions are "catalogued" but not initialized. This allows the module-name to module-context binding mechanism to work for the extension module.

Later, after boot, the user's code imports one of the extensions:

import mpeg-player

The import function recognizes that the extension module must still be initialized, and goes ahead with that, creating its context, bindings, functions, commands, etc.

Hosted Extensions

The A98 release will allow the host to add resident extensions during boot.

This is done by calling a new R3 lib API function:

REBAPI int Reb_Extend(REBYTE *spec, int (*call)(int, RXIFRM *))

The spec is the UTF-8 source for the extension module as described in Making Extensions. The call is the extension function dispatcher function, RX_Call. The RX_Init and RX_Quit functions are not used. (Q: Do we need them?)

Multiple extensions can be added by calling this function for each one. Each extension is only cataloged, not initialized at this time.

A hosted extension can be initialized in one of three ways:

1. Automatically during R3 boot
   If it specifies a boot priority in its module header, it is automatically initialized according to that priority. Higher priorities are initialized first.
2. From the boot script
   Within the host boot script run by Reb_Do_Binary() by calling the import function with the name of the extension module. This allows the host boot script to control if and when the extension is added.
3. Within user programs
   Normally by using the import function. This allows an extension to remain uninitialized until it is needed.