It is now possible to save workspaces and customize the initialization and top level functions. The function save-workspace takes a single argument, the name of the saved workspace file. It closes all windows and menus, creates the saved workspace, and exits from the system. The workspace file is created with a .wks extension.
On UNIX, and eventually MS Windows, a saved workspace can be loaded by specifying -w file.wks (with no spaces) as a command line argument. On a Macintosh, you can double click a workspace. If no workspace argument is given, the workspace named xlisp.wks in the startup directory is used if one is available. Otherwise, a file init.lsp is loaded. (So init.lsp is not loaded if a workspace is found). It is currently not possible to load a new workspace once the system has started up.
After loading a workspace or the init.lsp file, files on the command line (or files that where double clicked on the Macintosh) are loaded. The command line used to start up XLISP-STAT is also made available as a list of strings in the variable *command-line* . (On the Macintosh this variable currently does not contain anything useful.) Next, the functions of no arguments in the list that is the value of *startup-functions* is called. One of the functions in the default value of this variable is responsible for loading the statinit.lsp file. Finally, the function *top-level-loop* is called. This function is called again each time the system is reset to the top level.
The installed versions of xlispstat are now set up to start from a default xlisp.wks saved workspace rather than by loading a set of .lsp files. Compiled versions of files needed less frequently and help information are still kept in a library and loaded on demand.
The basic objective here is to make startup and the top level customizable. The details are likely to change somewhat as I get things straightened out on the Mac and Windows versions.
The ability to save workspaces (and to byte compile files) creates a problem for using
#-to test for runtime properties. These tests occur when a file is read. But a file can be read on a computer with a color display and the definitions can then be used from a saved workspace on a monochrome display, for example. As a result,
#-should only be used for properties, such as the operating system type, that will not change from one invocation to another. Runtime tests, such as the function screen-has-color should be used instead. All system files should have been rewritten with this in mind.