Muq is designed to be a highly extendable framework from which more specialized servers and applications can be built: Muq systems can and should extend both Muq and MUF in a wild variety of ways. "Let a thousand flowers bloom."
Amid this sea of chaos, one wishes to preserve a central isle of stability from which the visitor may survey the scene: This chapter defines a core layer of functionality which every Muq MUF implementation should support, which I hope is large enough to facilitate the construction of portable packages, yet small enough that supporting the full Core is not an undue burden on smaller implementations (tempting them to implement only a subset).
This chapter documents both muf prims and in-db muf functions.
"Prim" is short for "primitive". Prims are so called not because they are unsophisticated, but because they are the atomic, irreducible components from which other code in the system is built up(3).
The muf prims are those hardcoded in C in the server itself, as opposed to library functions coded in muf (or another in-db language) and compiled into muq bytecodes.
From a system implementation perspective, prims and library functions are quite different:
Prims may execute up to about one hundred times faster than library functions, but are trickier to code, require restarting the server to update, and may crash the entire server if defective, or failing that may corrupt the db or punch unintended holes in the security kernel. Prims also are locked into the executable image, meaning that they have to be loaded into ram every time the server starts up, and tend to stay in ram as long as it is running: a Muq server could fairly easily support half a gigabyte of library functions (since they would just sit on disk in the db until actually needed), but most contemporary workstations would be overwhelmed by half a gigabyte of primitives.
From the typical Muq programmer's point of view, however, there is rarely any need to distinguish between prims and library functions: The syntax is identical in either case.
So much so that we explicitly reserve to the implementor the decision as to what Core functionality to implement inserver, and what to implement in-db: We deem unportable and nonstandard any MUF code written to depend on the mode of implementation of any Core function.
This manual does document which functions are prims, and which in-db MUF-coded, but such knowledge should be used only to satisfy curiosity and for performance tuning.
By convention, MUF-coded Core functionality is kept in the muq/[0-9][0-9]-C-*.muf files.
Go to the first, previous, next, last section, table of contents.