The I/O subsystem, described in the previous section, provides support for input and output using SML that is largely independent of the underlying implementation and operating system. This section discusses other system aspects, such as processes, file systems, time, date and device-specific I/O attributes, and models for manipulating these resources that are agains largely system-independent.
The Basis Library specifies very little about the environment in which SML programs are executed. This gives implementations the widest possible freedom. Programs may be executed as part of an interactive session, as standalone executables, or as server processes.
However, there are a few points where the surrounding environment does impinge on the Basis Library. We summarize these points here.
The CommandLine structure defines functions that return the name and arguments with which a program was invoked. The method for setting these values is entirely up to the implementation. We would expect that if a stand-alone executable is run from a command line, then these values would be determined from the name and arguments specified on that command line.
Implementations may provide a mechanism for taking a function and producing a stand-alone executable. If such a mechanism is provided, the type of the function being exported must be
(string * string list) -> OS.Process.statusWhen the stand-alone executable is invoked, the function should be called with a first argument equal to
CommandLine.name ()and a second argument equal to
The OS.Process.getEnv function assumes that the environment associates a set of (name, value) pairs with the invocation of a program, where both name and value are strings. This function returns the value associated with a given key. The method for specifying this set is OS-dependent. The set may be empty.
The OS.Process.exit and OS.Process.terminate functions return a status value to the environment. The type of this value, and how the environment interprets it, is OS-dependent.
The OS.Process.atExit function adds an argument function to the actions that are executed when the program reaches a normal termination. A normal termination is a call to OS.Process.exit, or as defined by the implementation. If a stand-alone executable is created from a function as above, then normal termination occurs when that function returns. We would expect other methods for creating stand-alone executables to behave similarly.
Abnormal terminations include calls to OS.Process.terminate, or when a stand-alone executable does not handle a raised exception. The functions registered by OS.Process.atExit are not evaluated in the event of an abnormal program termination.
Some actions are implicitly registered with OS.Process.atExit, so that they always occur on a normal program termination. These must include the flushing and closing of all open outstreams created by the open functions in BinIO and TextIO, and the flushing (but not closing) of TextIO.stdOut and TextIO.stdErr. Although this covers most usual cases, for maximum portability and robustness code should flush streams explicitly.
Last Modified September 1, 1997
Comments to John Reppy.
Copyright © 1997 Bell Labs, Lucent Technologies