MAINSAIL system procedures, macros, and variables are described starting in Chapter 30, which should be consulted for information on unfamiliar identifiers in this manual.

1.1. Version

1.2. The History of MAINSAIL and XIDAK

In 1980, the original authors of MAINSAIL decided to commercialize the language. They founded XIDAK, Inc., in order to sell MAINSAIL. The name XIDAK is derived from the final consonants of the last names of the three original authors of MAINSAIL (Clark Wilcox, Greg Jirak, and Mary Dageforde). The founders selected two vowels (“I” and “A”) that are common to more than one of the last names, and arranged the letters into something pronounceable (“ZIE dack”).

1.3. The Design of MAINSAIL

Sizes and layouts of data types and data structures, values of system macro constants, and other system-dependent information may change from release to release and vary from system to system. For portability (both among different releases and different computers), these quantities should be specified symbolically using the features provided in the MAINSAIL language, and never hardwired into a program.

1.4. Terminology and Symbols

In descriptions, the forms (LONG) INTEGER, (LONG) BITS, and (LONG) REAL mean “INTEGER and/or LONG INTEGER”, “BITS and/or LONG BITS”, and “REAL and/or LONG REAL”, respectively.

MAINSAIL keywords (e.g., BEGIN, END) are written in all upper case in this manual, though this is not necessary in MAINSAIL programs. MAINSAIL does not distinguish identifiers or keywords on the basis of case.

Compiletime refers to actions that take place while a program is being compiled. Runtime refers to actions that take place while a program is being executed.

MAINSAIL implementations are categorized according to processor, operating system, and platform. A processor is characterized by a particular instruction set; one or more operating systems may run on computers containing a given processor. In XIDAK terminology, two implementations of MAINSAIL run on different operating systems if code for the two systems must be compiled differently (even if the instruction sets are the same, operating-system-dependent logic may have to be different). Platform is a narrower category than operating system; i.e., every operating system includes one or more platforms. Although identical code is generated for all MODULEs compiled for the same operating system, two different platforms within the same operating system may require different installation procedures or bootstraps, or may make slightly different operating system calls at runtime. The current lists of processors, operating systems, and platforms are given in Appendix B.

The target system (or target processor, target operating system, or target platform) is the computer system for which a MAINSAIL program is compiled, i.e., the system on which it is to run. In referring to compilations, the host system is the system on which a MAINSAIL program is compiled, which is not necessarily the same as the target system.

Error refers to a situation or language construct that by default generates an error message (either at compiletime or at runtime). Illegal refers to some language constructs that generate errors at compiletime. Undefined refers to a situation or language construct that is unsafe or not logically correct, but that may or may not generate an error message. Programs making use of an undefined construct or situation may not work the same way from one MAINSAIL version or implementation to another. Unspecified refers to the result of a situation or operation that does not generate an error and is not logically incorrect, but that may vary from situation to situation or from implementation to implementation. For example, in operations that round numbers, the direction of rounding is often unspecified.

MAINSAIL often chooses to leave a construct undefined or unspecified for efficiency considerations. On MAINSAIL implementations, the fastest form of an operation provided by the underlying hardware or operating system is usually used, regardless of whether it provides error condition checks or high precision.

Some error messages can be suppressed; e.g., the NOCHECK compiler directive prevents certain situations from generating error messages. Suppressing error messages with the NOCHECK directive transforms the affected error situations into undefined situations.

1.5. Conventions Used in This Document

Prompt: response<eol>

name of addressee
street number  street name
town or city name, state abbreviation  zip code

or as:

<name of addressee>
<street number> <street name>
<town or city name>, <state abbreviation>  <zip code>

Optional elements in command or syntax descriptions are often enclosed in curly brackets ({ and }). For example, a string of characters specified as {A}B{C} could have any one of the forms B, BC, AB, and ABC. Optional arguments followed by an asterisk (*) may be repeated zero or more times, so that {A}* can mean nothing, or A, or AA, or AAA, etc.

Alternatives may be enclosed in square brackets (or curly brackets, if all alternatives are optional) and separated by vertical bars (|); [A|B|C] means A, B, or C; {A|B} means A, B, or nothing.

1.5.3. Temporary Features