"Program" is a concept imposed by lazy operating-system designers on reluctant programmers, as a way of locking useful functions away from each other and the programmer at runtime: Programming environments designed by and for programmers almost invariably lack the concept of a program: Lisp, Smalltalk, Forth, APL...
Muq being intended to be a pleasant programming environment, it likewise lacks the concept of a "program": subject to privacy mechanisms, any function is free to refer to any other function, and the programmer may invoke any function at any time without needing to pry the lid off any black box.
Eliminating the concept of "program" does not, however, eliminate the need for modularity, namespace control, and the ability to group code and data into units larger than that of an individual datum or executable.
Lisp, being older than Fortran, has had some half a century now to grapple with this problem, and has produced packages as an answer. Not seeing any reason to believe that I can improve sufficiently on the collective wisdom of the Lisp community to justify imposing a more idiosyncratic solution on the Muq user community, I have configured Muq to follow CommonLisp here as closely as seems practical.
A Muq package is nothing more or less than an object whose public and hidden properties are all symbols. Since symbols have names, know to which package they belong, and have value and function slots, this means that symbols provide convenient little wrappers in which values may be passed to functions and users, who will then be able to simply use the provided value, if desired, or else be able to print its name and package affiliation, if the user should become curious as to where the value came from and what it means.
Muq symbols serve as generic global variables; Muq packages serve as sets of related symbols (representing both code and data) which may then be included as a single unit in the programming environment of a given Muq programmer: Muq packages play something of the role of library as well as the vestigal roles of programs.
Packages may contain both public symbols exported to anyone using the package, and also private symbols intended only for internal use, hence they also possess something in the nature of an interface specification, and provide a simple, generic form of encapsulization.
All symbols "present" in a package are listed in it as hidden keys.
All symbols "exported' from a package are in addition listed in it as public keys, making them available for general external access.
A package P may "use" another package Q: this means that all symbols exported from Q are known in P, and may be freely used in P more or less as though they were present in P.
At a given time in a given job @, @.package is the currently open package, and @.lib is an object, public keys of which represent the universe of packages treated as known to the job.
Class Package adds the following properties to those of Class Plain:
$S.nicknames: An object, public keys of which are interpreted as
nicknames for the package.
$S.shadowingSymbols:
An object, public keys of which are interpreted as
symbols which are to silently win name conflicts
in the current package.
$S.usedPackages:
An object, public keys of which are interpreted
as packages "used" by the package.
Note: For convenience, the $S properties are also available in the public (default) propdir.
Go to the first, previous, next, last section, table of contents.