Although many modules are self-contained, dependencies may exist. For example, the system module, Sys , provides basic services that many other modules require. These are the Inferno equivalent to `system calls'.
In a few cases, several related modules share a single include file; for instance, security.m .
The manual pages describe how to include a module definition during compilation and load an implementation during execution. The documentation also lists relevant functions or abstract data types. Although the include files declare these components, the manual pages list them explicitly. In all cases, the enclosing module declaration is assumed so that unqualified identifiers can be used in the text without ambiguity, reducing clutter in the text. In practice when programming, many consider it good style to use an explicit module reference for functions and constants.
The Limbo modules are identical on any machine that is running Inferno, whether native or hosted, which enables Limbo programs to be written and tested on any Inferno system.
Many modules are described in a single page, such as regex (2). Several larger modules are explained in several sections, such as math-intro (2), math-elem (2), math-fp (2), and math-linalg (2).
"alt send/recv on same chan" It is currently illegal for a channel to appear in two alt statements if they either both receive or both send on it. (It is fine to send in one and receive in the other.)
"array bounds error" Array subscript out of bounds.
"dereference of nil" Attempt to use a "ref" adt or index an array with value "nil" .
"invalid math argument" Inconsistent values provided to functions of math-intro (2).
"module not loaded" Attempt to use an uninitialised module variable.
"negative array size" The limit in an array constructor was negative.
"out of memory:" " pool" The given memory pool is exhausted. Pool is currently one of main (kernel memory including Tk allocations), heap (most Limbo data), and image memory for draw (3).
"zero divide" Integer division (or mod) by zero.
There are currently two more classes of exception string with a conventional interpretation imposed not by the run-time system proper, but by Limbo components:
"fail:" "reason" Commands use this exception to provide an `exit status' to a calling program, particularly the shell sh (1); see also sh (2). The status is given by the reason following the ` fail: ' prefix.
"assertion:" "error" A module detected the specified internal error . This is most often used for cases where a particular possibility ``cannot happen'' and there is no other need for an error value in the interface.
Otherwise, most module interfaces tend to use explicit error return values, not exceptions.
Note that a Limbo exception handler can do pattern matching to catch a class of exceptions:
.EX { \f2body of code to protect } exception e { "out of memory:*" => \f2recovery action "assertion:*" => fatal_error(e); }The effect of an unhandled exception in a process that is part of an error-recovery group can be controlled using the mechanisms described in prog (3) as accessed using exception (2).