Toggle menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.


From wiki
(Redirected from Libpacks)

Besides direct editing, linking is one of the main vectors for end-user control and customization.

The triple script module system will also be extended to accommodate some kind of "libpacks"—filling a similar role to shared objects in the world of "native" executables. These will be pre-compiled bundles that are still intended to be dropped into a repo and vendored like script modules, but the bundle will be an agglomeration of modules likely to be maintained independently of the project and upgraded all-at-once.

Linkage model[edit]

The triple script linkage model can be understood in terms of the model used for the C programming language, even though they are not the same model. To achieve sane external linkage, each module is allocated at most one privileged binding—which is privileged in the sense that this binding is permitted promote a name from internal linkage (with respect to the module) into the program's global scope. (Any other top-level binding is unprivileged, i.e. it cannot be an export, although imports are allowed.) This global scope is shared among all a program's modules—which due to the self-containedness philosophy are all linked into the same file.

There can be no name collisions, because the triple script execution environment has no way to resolve them.

Name bindings at the top-level are generally statically resolvable, being either an export or created with import statements, with exactly one escape hatch: typeof checks. With typeof, a programmer can defer the binding of a given name to runtime, while keeping name visibility statically decidable. A program can thus interface with user-supplied modules/libpacks without the program's original author having explicitly and statically linked against those targets themselves. I.e., the user may concretely link in new modules (producing a new file, consisting of the original program augmented with the additional modules), or execute the triple script in an environment that dynamically achieves the equivalent (with no intermediate file produced). The latter should be rare and happen solely at the direction of the user, rather than it being typical for program authors to distribute code with the intent (or requirement) that it be used this way. The self-containedness principle is one of the three pillars of the triple script philosophy, and is not optional.

See also[edit]

Selective reification

Cookies help us deliver our services. By using our services, you agree to our use of cookies.