Compiletime Libraries

Compiletime libraries (also called "source libraries") are a technique for creating a repository of procedures used by a number of modules. The introduction of intmods has made this technique more or less obsolete, since intmods are more flexible in that they can contain common

variables as well as common procedures and they are more efficiently compiled. Nonetheless, users may need to examine or maintain existing compiletime libraries, so this section has been retained.

The compiler directives "NEEDBODY(p)", "NEEDANYBODIES", "NEEDANYBODIES (c) " , and "FORW ARD(c)" are all provided to promote the use of compiletime libraries. A

compiletime library is a file that contains procedure bodies that can be "compiled into" a number of different modules.

The diagrams and text in Example 6.1-1 shows the use of a compiletime library. Each procedure declaration in the file "lib" is surrounded by the directives shown in Example 6.1-2.

<eop>

BEGINSCAN

...

IFC NOT NEEDBODY(p) THENC SKIPSCAN PROCEDURE p;

BEGIN

.•. <procedure body> . . . END;

"". t ENDC

IFC NOT NEEDANYBODIES("lib") THENC DONESCAN; ENDC

<eop>

Example 6.1-2. Declaration of Procedures in "lib"

Any procedure declared forward in "hdr", and called in mi (but not given a body there), causes an automatic sourcefile of "lib". In "lib", the conditional compilation and compiler directives result in the compilation of only those procedures which were used (called) in mi. The use of

"NEEDANYBODIES" together with "DONESCAN" is an optimization to stop compilation of

header file "hdr"

+---+

lmacro definitions Iclass declarations Imodule declarations

I forward procedure declarations I (each procedure header is

compiletime library "lib"

+---+

Example 6.1-1. Use of a Compiletime Library

To convert a compiletime library to an intmod, go through the file(s) containing the procedure bodies (in this case, "lib") and remove all the directives bracketing each procedure declaration.

Add the directives:

SAVEON;

$DIRECTIVE "NOGENCODE";

to the file "hdr", and add:

BEGIN "hdr"

and:

END "hdr"

at the beginning and end of "hdr", respectively. "hdr" is now the source file for an intmod, which can be used (once it has been compiled) by modules that contain:

RESTOREFROM "hdr";

If any of the procedures requires "private" procedure or outer variable or macro declarations, these may be hidden from the using module with the symbol visibility directives. For example, to hide a symbol "xxx", include the line:

$DlRECTIVE "MAKENOTVISIBLE xxx";

before the end of "hdr" .

Most compiletime libraries can be converted to intmods. Sometimes, however, the procedures in a compiletime library may use identifiers that have been defined before their bodies are picked up from the compile time library; e.g., a procedure might use an identifier "xxx" that it expects the calling module to have defined. Such procedures with source dependencies cannot be converted to procedures in intmods, since all identifiers in them must be defined when the intmod is compiled.

6.2. MAINED Editing Techniques

6.2.1. Deleting in Insert Mode

If you want to delete some stuff at the end of a line, and replace it with some other stuff, just go into insert mode and press the delete key. This deletes old text to the left

6.2.2. Search and Replace Macro To define a search and replace macro:

t<search string><eol>

/<macro id>

<do the replacement>t<search string><eol>

/

6.2.3. Defining Mode-Independent Macros with "QRM"

A macro execution can leave MAINED in command mode (or some other mode explicitly specified in the macro), or it can leave it in the mode which was in effect when the macro was invoked. The "QRM" command restores the saved mode (remembered at the start of macro execution). For example, to define a macro to search for "foo" and retain the editor mode, issue the following commands:

/<macro Id>t foo<eol>qrm<ecm>/

The editor mode remains unchanged by the invocation of <macrold>. The "QRM" command works for named as well as for unnamed macros.

6.3. Rationale for MAINSAIL's Binding Rules

Often, interface variables do not really "belong" to any module (they are equally shared by a number of modules) so that it is natural to put them in a single interface. In those cases when some interface variables are naturally associated with a module which would not necessarily bound when the variables are accessed, the programmer must choose between moving those variables to a "root" module that will be bound when the variables are accessed and explicitly binding the module with the interface variables in all modules that access the variables ... There are good reasons why MAINSAll.. imposes this minor inconvenience instead of automap.cally binding every module accessed by m when m is allocated or binding a module whenever one of its interface variables is accessed:

• Automatically binding every module accessible from m when m was allocated would lead to an "explosive" allocation of all potentially accessible modules in the entire progmm, since the allocation of each module would in ttun cause the allocation of all its referenced modules. This defeats MAINSAIL's concept of a program as an open-ended collection of modules brought into execution only as necessary. For example, the runtime system contains many modules, perhaps only a few of which are used during a particular program execution. Also, it is common for an initial procedure to allocate data sttuctures such as arrays; it would be potentially fatal to program execution if all such arrays were allocated at once.

• The check required to allocate a module on intermodule data access would make intermodule data access substantially less efficient.