There are two areas where there are composability concerns:
- when a general purpose libpack that we link against is itself a valid triple
script (we need to transform its shunting block; maybe this should be as simple as truncating the IIFE with a semicolon—replacing the invocation parens)
- distinct from the case of linking against an existing program for use as a
lib, we want to be able to more-or-less contrive of a format that allows us to chain multiple programs together in a "pipe"
A use case for the latter: suppose program A only natively supports attaching to a file source via officially non-standard but reasonably widely supported APIs, but nonetheless the operator is kept from using A because they are forced to use a runtime where these APIs are not available. Program Z is written as a self-contained but mostly useless script that puts a text input on the screen meant to accepting the textual output of xxd or od (by way of the clipboard), attempts to reconstruct it into a buffer while assuming that it's a well-formed ZIP file, thus creating a read-only in-memory file system from the buffer, and then outputting a ZIP by default. We should offer a way to compose programs A and Z such that Z is given initial control, and then A is given control—being able to make use of Z's in-memory filesystem. Furthermore, keeping our use case in mind, whatever the process entails for linking A and Z into a single self-contained object, this should be trivial to do by hand, given only access to a dumb text editor and the compilation texts of A and Z.
(One approach is to exploit the fact that Z is authored with the a priori assumption that it will be used in this way, and simply design Z such that it accepts as a second textual input the program text for A--or any other valid triple script--analyzes A for conformance to a particular protocol, and then attempts to do its own chainloading internally. This is less than ideal that the "reified pipelines" approach described above.)