Google
 

Trailing-Edge - PDP-10 Archives - decus_20tap1_198111 - decus/20-0002/sail.tut
There is 1 other file named sail.tut in the archive. Click here to see a list.
			      SAIL TUTORIAL

			     Nancy W. Smith

			 SUMEX Computer Project






			      August, 1976




Note:  This is a computer-readible copy of the SAIL Tutorial
published by the Stanford Artificial Intelligence Project.
The original publication is the preferable form.
                   T A B L E   O F   C O N T E N T S



SECTION                                                             PAGE



1  Introduction                                                        1



2  The ALGOL-Part of Sail                                              3

   1  Blocks                                                           3
   2  Declarations                                                     4
   3  Statements                                                       7
   4  Expressions                                                     15
   5  Scope of Blocks                                                 21
   6  More Control Statements                                         24
   7  Procedures                                                      30


3  Macros                                                             38



4  String Scanning                                                    42



5  Input/Output                                                       46

   1  Simple Terminal I/O                                             46
   2  Notes on Terminal I/O for TENEX Sail Only                       46
   3  Setting Up a Channel for I/O                                    47
   4  Input from a File                                               58
   5  Output to a File                                                60


6  Records                                                            61

   1  Declaring and Creating Records                                  61
   2  Accessing Fields of Records                                     62
   3  Linking Records Together                                        63


7  Conditional Compilation                                            67



8  Systems Building in Sail                                           69

   1  The Load Module                                                 70
   2  Source Files                                                    72
   3  Macros and Conditional Compilation                              73


    APPENDIX A:  Sail and ALGOL W Comparison                          74


    REFERENCES                                                        77


    INDEX                                                             78


                               SECTION  1

                              Introduction




The  Sail  manual  [1]   is  a  reference  manual   containing  complete
information on Sail but may be difficult for a new user of  the language
                                            *
to work with.  The purpose of this TUTORIAL   is to introduce  new users
to the language.  It does not deal in depth with advanced  features like
the LEAP portion of Sail; and uses pointers to the relevant  portions of
the manual  for some descriptions.   Following the pointers  and reading
specific  portions  of  the  manual  will  help  you  to   develop  some
familiarity  with  the  manual.    After  you  have  gained   some  Sail
programming  experience, it  will be  worthwhile to  browse  through the
complete reference manual to find a variety of more  advanced structures
which  are  not  covered in  the  TUTORIAL  but may  be  useful  in your
particular programming tasks.   The Sail manual  also covers use  of the
BAIL debugger for Sail.

The TUTORIAL is not at an appropriate level for a computer  novice.  The
following assumptions are made about the background of the reader:

       1)  Some experience with the PDP-10 including knowledge  of an
   editor,  understanding of  the file  system, and  familiarity with
   routine utility programs  and system commands.   If you are  a new
   user or have previous experience only on a non-timesharing system,
   you should read the TENEX  EXEC MANUAL [7] (for TENEX  systems) or
   the DEC USERS HANDBOOK  [6] (for standard TOPS-10 systems)  or the
   MONITOR  MANUAL  [3]  and  UUO MANUAL  [2]  (for  Stanford  AI Lab
   users).  In addition,  you might want  to glance through  and keep
   ready  for reference:  the TENEX  JSYS MANUAL  [8] and/or  the DEC
   ASSEMBLY LANGUAGE HANDBOOK [5].  Also, each PDP-10  system usually
   has its  own introductory  material for  new users  describing the
   operation of the system.

       2)  Some  experience  with  a  programming  language--probably
   FORTRAN,  ALGOL  or  an   assembly  language.   If  you   have  no
   programming  experience, you  may need  help getting  started even
   with  this  TUTORIAL.   Sail  is based  on  ALGOL  so  the general
   concepts and most of the actual statements are the same in what is
   often called  the "ALGOL  part" of Sail.   The major  additions to
   Sail are its input/output routines.  Appendix A contains a list of
   the differences between the ALGOL W syntax and Sail.

Programs written in standard Sail (which will henceforth be called TOPS-
10  Sail)  will usually  run  on  a TENEX  system  through  the emulator
(PA1050)  which  simulates the  TOPS-10  UUO's, but  such  use  is quite
inefficient.  Sail also has a  version for TENEX systems which  we refer
to as  TENEX Sail.  (The  new TOPS-20 system  is very similar  to TENEX;
either TENEX  Sail or a  new Sail version  should be running  on TOPS-20
shortly.) Note  that the  Sail compiler  on your  system will  be called
simply Sail but will  in fact be either  the TENEX Sail or  TOPS-10 Sail
version of  the compiler.  Aside  from implementation  differences which
will not be discussed here,  the language differences are mainly  in the
input/output (I/O) routines.  And of course the system level commands to
compile, load, and run a  finished program differ slightly in  the TENEX
and TOPS-10 systems.



















































___________
*
     I would like to thank  Robert Smith for editing the  final version;
and Scott  Daniels for  his contributions to  the RECORD  section.  John
Reiser, Les Earnest,  Russ Taylor, Marney  Beard, and Mike  Hinckley all
made valuable suggestions.


                               SECTION  2

                         The ALGOL-Part of Sail




2.1  Blocks

Sail is a block-structured language.  Each block has the form:

        BEGIN

        <declarations>
            .
            .

        <statements>
            .
            .

        END

Your entire program will be a block with the above format.  This program
block is a somewhat special block called the outer block.  BEGIN and END
are reserved words  in Sail that mark  the beginning and end  of blocks,
with the outermost BEGIN/END pair also marking the beginning and  end of
your  program.   (Reserved  words  are  words  that  automatically  mean
something to Sail; they are called "reserved" because you should not try
to give them your own meaning.)

Declarations are used  to give the  compiler information about  the data
structures  that you  will be  using  so that  the compiler  can  set up
storage locations  of the  proper types and  associate the  desired name
with each location.

Statements form the bulk of your program.  They are the  actual commands
available in Sail to use for coding the task at hand.

All  declarations in  each  block must  precede all  statements  in that
block.  Here is a very simple one-block program that outputs  the square
root of 5:

                   BEGIN
DECLARATIONS  ==>  INTEGER i;
                   REAL x;
STATEMENTS    ==>  i _ 5;
                   x _ SQRT(i);
                   PRINT("SQUARE ROOT OF  ", i,
                         "  IS  ", x);
                   END

which will print out on the terminal:

        SQUARE ROOT OF  5  IS  2.236068   .


2.2  Declarations 

A list  of all the  kinds of  declarations is given  in the  Sail manual
(Sec. 2.1).  In this section  we will cover type declarations  and array
declarations.   Procedure  declarations  will  be  discussed  in Section
2.7.   Consult  the  Sail  manual  for  details  on  all  of  the  other
varieties of declarations listed.

2.2.1  Type Declarations

The purpose of type declarations  is to tell the compiler what  it needs
to know to set up the  storage locations for your data.  There  are four
data types available in the ALGOL portion of Sail:

       1)  INTEGERs are counting  numbers like -1,  0, 1, 2,  3, etc.
   (Note  that commas  cannot  be used  in numbers,  e.g.,  15724 not
   15,724.)

       2)  REALs are  decimal numbers  like -1.2,  3.14159, 100087.2,
   etc.

       3)  BOOLEANs are assigned the values TRUE or FALSE  (which are
   reserved words).  These are predefined for you in Sail (TRUE  = -1
   and FALSE = 0).

       4)  STRINGs  are  a data  type  not found  in  all programming
   languages.   Very often  what  you will  be working  with  are not
   numbers at all but text.  Your program may need to output  text to
   the user's terminal while  he/she is running the program.   It may
   ask the user questions and  input text which is the answer  to the
   question.  It may in fact process whole files of text.  One simple
   example of this is a program which works with a file  containing a
   list of words and outputs to a new file the same list of  words in
   alphabetical  order.   It  is  possible  to  do  these  things  in
   languages  with only  the  integer and  real data  types  but very
   clumsy.   Text  has  certain properties  different  from  those of
   numbers.  For example,  it is very useful  to be able to  point to
   certain of  the characters in  the text and  work with  just those
   temporarily or to take  one letter off of  the text at a  time and
   process it.  Sail has  the data type STRING for  holding "strings"
   of text characters.  And associated with the STRING data  type are
   string operations that work in a way analogous to how  the numeric
   operators  (+,-,*, etc.)  work with  the numeric  data  types.  We
   write the actual strings enclosed in quotation marks.  Any  of the
   characters  in the  ASCII  character set  can be  used  in strings
   (control characters, letters, numerals, punctuation  marks).  Some
   examples of strings are:

       "OUTPUT FILE= "
       "HELP"
       "Please type your name."
       "aardvark"
       "0123456789"
       "!""#$%&"
       "AaBbCcDdEeFf"

       ""     (the empty string)
       NULL   (also the empty string)


   Upper and lowercase letters  are not equivalent in  strings, i.e.,
   "a" is a different  string than "A".  (Note that  to put a "  in a
   string, you use "", e.g., "quote a ""word""".)

In your programs, you will  have both variables and constants.   We have
already given  some examples  of constants  in each  of the  data types.
REAL and  INTEGER constants  are just  numbers as  you usually  see them
written (2, 618, -4.35, etc.); the BOOLEAN constants are TRUE and FALSE;
and  STRING constants  are  a sequence  of text  characters  enclosed in
double quotes (and NULL for the empty string).

Variables are used rather than constants when you know that a value will
be needed in the given computation  but do not know in advance  what the
exact value will be.   For example, you may  want to add 4  numbers, but
the numbers will  be specified by  the user at  runtime or taken  from a
data file.  Or the numbers may be the results of  previous computations.
You might be computing weekly totals and then when you have  the results
for each week  adding the four weeks  together for a monthly  total.  So
instead of  an expression  like 2 + 31 + 25 + 5  you need  an expression
like X + Y + Z + W  or WEEK1 + WEEK2 + WEEK3 + WEEK4.   This is  done by
declaring (through  a declaration) that  you will need  a variable  of a
certain data  type with a  specified name.  The  compiler will set  up a
storage location of the proper  type and enter the name and  location in
its symbol table.  Each time that you have an intermediate  result which
needs to  be stored, you  must set up  the storage location  in advance.
When  we discuss  the  various statements  available, you  will  see how
values  are  input  from  the  user or  from  a  file  or  saved  from a
computation and stored in the appropriate location.  The names for these
variables are often referred  to as their identifiers.   Identifiers can
be as long (or  short) as you want.   However, if you will  be debugging
with DDT or  using TOPS-10 programs  such as the  CREF cross-referencing
program,  you  should make  your  identifiers unique  to  the  first six
characters, i.e., DDT can  distinguish LONGSYMBOL from LONGNAME  but not
from  LONGSYNONYM  because  the   first  6  characters  are   the  same.
Identifiers must begin with a  letter but following that can be  made up
of any  sequence of  letters and numbers.   The characters  ! and  $ are
considered  to  be  letters.   Certain  reserved  words  and predeclared
identifiers are unavailable for use as names of your own identifiers.  A
list of these is given in the Sail manual in Appendices B and C.

Typical declarations are:

        INTEGER i,j,k;
        REAL x,y,z;
        STRING s,t;

where these are  the letters conventionally  used as identifiers  of the
various types.  There is no reason why you couldn't have INTEGER x; REAL
i; except that other people reading your program might be  confused.  In
some languages the letter used for the variable automatically  tells its
type.   This  is  not  true  in  Sail.   The  type  of  the  variable is
established  by   the  declaration.    In  general,   simple  one-letter
identifiers like these are used for simple, straightforward  and usually
temporary purposes such as to  count an iteration.  (ALGOL W  users note
that iteration variables must be declared in Sail.)

Most of the variables  in your program will  be declared and used  for a
specific purpose and the name you specify should reflect the use  of the
variable.


        INTEGER nextWord, page!count;
        REAL total, subTotal;
        STRING lastname, firstname;
        BOOLEAN partial, abortSwitch, outputsw;

Both upper and  lowercase letters are  equivalent in identifiers  and so
the case as well as the use of ! and $ can contribute to the readability
of your programs.   Of course, the above  examples contain a  mixture of
styles; you will want  to choose some style  that looks best to  you and
use it consistently.  The equivalence of upper and lowercase  also means
that

        TOTAL | total | Total | toTal | etc.

are all instances of the same identifier.  So that while it is desirable
to be consistent, forgetting occasionally doesn't hurt anything.

Some  programmers  use  uppercase for  the  standard  words  like BEGIN,
INTEGER, END, etc. and lowercase for their identifiers.   Others reverse
this.   Another  approach  is  uppercase  for  actual  program  code and
lowercase for comments.  It is important to develop some style which you
feel makes your programs as easy to read as possible.

Another important element  of program clarity  is the format.   The Sail
compiler  is free  format which  means that  blank  lines, indentations,
extra spaces, etc. are ignored. Your whole program could be on  one line
and the compiler  wouldn't know the  difference.  (Lines should  be less
than  250 characters  if  a listing  is  being made  using  the compiler
listing  options.)  But   programs  usually  have  each   statement  and
declaration on a separate line with all lines of each block indented the
same number of spaces.  Some  programmers put BEGIN and END on  lines by
themselves and others put them on the closest line of code.  It  is very
important to format your programs so that they are easy to read.



2.2.2  Array Declarations

An array is a  data structure designed to let  you deal with a  group of
variables together.  For example, if you were accumulating weekly totals
over a period of a year, it would be cumbersome to declare:

        REAL week1, week2, week3,.....,week52 ;

and then have to work with the 52 variables each having a separate name.
Instead you can declare:

        REAL ARRAY weeks [1:52] ;

The array  declaration consists  of one  of the  data type  words (REAL,
INTEGER, BOOLEAN,  STRING) followed  by the word  ARRAY followed  by the
identifier followed by  the dimensions of the  array enclosed in  [ ]'s.
The dimensions give the bounds  of the array.  The lower bound  does not
need to be 1.   Another common value for the  lower bound is 0,  but you
may make it  anything you like.  (The  LOADER will have  difficulties if
the lower bound  is a number of  large positive or  negative magnitude.)
You may  declare more than  one array in  the same  declaration provided
they are the same type  and have the same dimensions.  For  example, one
array might be used for the total employee salary paid in the week which


will be  a real  number, but  you might  also need  to record  the total
employee hours  worked and the  total profit made  (one integer  and one
real value) so you could declare:

        INTEGER ARRAY hours [1:52];
        REAL ARRAY salaries, profits [1:52];

These 3 arrays are examples of parallel arrays.

It is also possible to have multi-dimensioned arrays.  A  common example
is an array used to represent a chessboard:

        INTEGER ARRAY chessboard [1:8,1:8];

        1,1  1,2  1,3  1,4  1,5  1,6  1,7  1,8
        2,1  2,2  2,3  2,4  2,5  2,6  2,7  2,8
         .    .    .    .    .    .    .    .
         .    .    .    .    .    .    .    .
         .    .    .    .    .    .    .    .
         .    .    .    .    .    .    .    .
         .    .    .    .    .    .    .    .
        8,1  8,2  8,3  8,4  8,5  8,6  8,7  8,8

In fact even  the terminology used is  the same.  Arrays,  like matrices
and chessboards, have  rows (across) and columns  (up-and-down).  Arrays
which are statically allocated (all outer block and OWN arrays) may have
at most 5 dimensions.   Arrays which are allocated dynamically  may have
any number of dimensions.

Each  element  of the  array  is a  separate  variable and  can  be used
anywhere that a simple variable  can be used.  We refer to  the elements
by giving the name of  the array followed by the  particular coordinates
(called  the subscripts)  of  the given  element enclosed  in  []'s, for
example: weeks[34], weeks[27], chessboard[2,5], and chessboard[8,8].



2.3  Statements

All of the  statements available in Sail  are listed in the  Sail manual
(Sec. 1.1 with the syntax for the statements in Sec. 3.1).  For  now, we
will  discuss the  assignment statement,  the PRINT  statement,  and the
IF...THEN statement which will allow us to give some sample programs.

2.3.1  Assignment Statement

Assignment statements are used to assign values to variables:

        variable _ expression

The variable being assigned to  and the expression whose value  is being
assigned to it are separated by the character which is a backwards arrow
in  1965 ASCII  (and  Stanford ASCII)  and is  an  underbar (underlining
character) in 1968 ASCII.  The assignment statement is often read as:

      variable becomes expression
  OR  variable is assigned the value of expression
  OR  variable gets expression


You may assign  values to any of  the four types of  variables (INTEGER,
REAL, BOOLEAN, STRING) or to the individual variables in arrays.

Essentially, an expression is something that has a value.  An expression
is  not  a  statement (although  we  will  see later  that  some  of the
constructions of  the language can  be either statements  or expressions
depending on the current use).  It is most important to remember that an
expression can be evaluated.  It is a symbol or sequence of symbols that
when  evaluated  produces  a  value that  can  be  assigned,  used  in a
computation, tested  (e.g. for  equality with  another value),  etc.  An
expression may be

       a)  a constant

       b)  a variable

       c)  a construction using constants, variables, and the various
   operators on them.


Examples of these 3 types of expressions in assignment statements are:

    DON'T FORGET TO DECLARE VARIABLES FIRST!

        INTEGER i,j;
        REAL    x,y;
        STRING  s,t;
        BOOLEAN isw,osw,iosw;
        INTEGER ARRAY arry [1:10];

    a)  i _ 2;         COMMENT now i = 2;
        x _ 2.4;       COMMENT now x = 2.4;
        s _ "abc";     COMMENT now EQU(s,"abc");
        isw _ TRUE;    COMMENT now isw = TRUE;
        osw _ FALSE;   COMMENT now osw = FALSE;
        arry[4] _ 22;  COMMENT now arry[4] = 22;

    b)  j _ i;         COMMENT now i = j = 2;
        y _ x;         COMMENT now x = y = 2.4;
        t _ s;         COMMENT now EQU(s,"abc")
                               AND EQU(t,"abc");
        arry[8] _ j;   COMMENT i=j=arry[8]=2;

    c)  i _ j + 4;     COMMENT j = 2 AND i = 6;
        x _ 2y - i;    COMMENT y=2.4 AND i=6
                               AND x = -1.2;
        arry[3] _ i/j; COMMENT i=6 AND j=2
                               AND arry[3]=3;
        iosw _ isw OR osw;   COMMENT isw = TRUE
                               AND osw = FALSE
                               AND iosw = TRUE;

   NOTE1:  Most of the operators for strings are different than those
       for the  arithmetic variables.  The  difference between  = and
       EQU will be covered later.

   NOTE2:  Logical operators  such as AND  and OR are  also available
       for boolean expressions.


   NOTE3:  You may put "comments"  anywhere in your program  by using
       the  word COMMENT  followed by  the text  of your  comment and
       ended with a semi-colon (no semi-colons can appear  within the
       comment).  Generally comments are placed  between declarations
       or statements rather than inside of them.

   NOTE4:  In all  our examples, you  will see that  the declarations
       and statements are separated by semi-colons.

In a  later section, we  will discuss: 1)  type conversion  which occurs
when the data types of the variable and the expression are not the same,
2)  the  order  of  evaluation  in  the  expression,  and  3)  many more
complicated expressions including  string expressions (first we  need to
know more of the string operators).



2.3.2  PRINT Statement

PRINT is a relatively new but very useful statement in Sail.  It is used
for  outputting  to  the  user's terminal.   You  can  give  it  as many
arguments as you want and the arguments may be of any type.  PRINT first
converts each  argument to a  string if necessary  and then  outputs it.
Remember that only strings can be printed anywhere.  Numbers  are stored
internally as 36-bit words and  when they are output in 7-bit  bytes for
text  the  results  are  very  strange.   Fortunately  PRINT   does  the
conversion to  strings for  you automatically, e.g.,  the number  237 is
printed as the string "237".   The format of the PRINT statement  is the
word PRINT followed by a list of arguments separated by commas  with the
entire list enclosed in parentheses.  Each argument may be any constant,
variable, or complex expression.   For example, if you wanted  to output
the weekly salary totals from  a previous example and the number  of the
current week was stored in INTEGER curWeek, you might use:

        PRINT("WEEK ", curWeek,
              ":  Salaries ", salaries[curWeek]);

which  for curWeek = 28  and the  array  element salaries[28] = 27543.82
would print out:

        WEEK 28: Salaries   27543.82

   NOTE:  The  printing format  for reals  (number of  leading zeroes
       printed and  places after the  decimal point) is  discussed in
       the Sail manual under type conversions.



2.3.3  Built-in Procedures

Using  just the  assignment statement,  the PRINT  statement,  and three
built-in procedures, we  can write a  sample program.  Procedures  are a
very important feature of Sail and you will be writing many of your own.
The details  of procedure  writing and  use will  be covered  in Section
2.7.   Without  giving any  details  now,  we will  just  say  that some
procedures to handle very common tasks have been written for you and are
available as built-in procedures.   The SQRT, INCHWL and  CVD procedures
that  we will  be using  here are  all procedures  which  return values.
Examples are:


        s _ INCHWL;
        i _ CVD(s);
        x _ 2 + SQRT(i);

Procedures may  have any number  of arguments (or  none).  SQRT  and CVS
have a single  argument and INCHWL has  no arguments (but does  return a
value).   The  procedure call  is  made by  writing  the  procedure name
followed by the argument(s) in parentheses.  In the expression  in which
it  is used,  the procedure  call  is equivalent  to the  value  that it
returns.

   SQRT returns the square root of its argument.

   CVD returns  the result  of converting its  string argument  to an
       integer. The string is assumed to contain a number  in decimal
       representation--CVO converts strings containing octal numbers,
       e.g., after executing

            i _ CVD("14724");  j _ CVO("14724");

       then the following

            i = 14724 AND j = 6612

       would be true.

   INCHWL  returns the  next  line of  typing  from the  user  at the
       controlling terminal.

   NOTE: In TENEX-Sail the INTTY procedure is available and SHOULD be
       used  in  preference  to the  INCHWL  procedure  for inputting
       lines.  This  may not  be mentioned in  every example,  but is
       very important for TENEX users to remember.

So, for the statement s  INCHWL; , the value of INCHWL will be the line
typed at the  terminal (minus the  terminator which is  usually carriage
return).  This  value is  a string and  is assigned  here to  the string
variable s.

So far we have seen five uses of expressions: as the  right-hand-side of
the  assignment  statement, as  an  actual parameter  or  argument  in a
procedure call, as  an argument to the  PRINT statement, for  giving the
bounds in an array declaration (except for arrays declared in  the outer
block which must have constant bounds), and for the array subscripts for
the elements of arrays.  In fact the whole range of kinds of expressions
can be used in nearly all the places that constants and variables (which
are particular  kinds of  expressions) can be  used.  Two  exceptions to
this  that  we  have  already seen  are  1)  the  left-hand-side  of the
assignment statement (you can assign a value to a variable but not  to a
constant or a more complicated  expression) and 2) the array  bounds for
outer  block arrays  which come  at a  point in  the program  before any
assignments have been made to any of the variables so only constants may
be  used--the declarations  in the  outer block  are before  any program
statements at all.

In general, any construction that  makes sense to you is  probably legal
in Sail.   By using some  of the more  complicated expressions,  you can
save yourself steps in your program.  For example,

        BEGIN


        REAL sqroot;
        INTEGER numb;
        STRING reply;
        PRINT("Type number: ");
        reply_INCHWL;
        numb_CVD(reply);
        sqroot_SQRT(numb);
        PRINT("ANS: ",sqroot);
        END;

can be shortened  by several steps.  First,  we can combine  INCHWL with
CVD:

        numb _ CVD (INCHWL);

and  eliminate  the  declaration  of  the  STRING  reply.   Next  we can
eliminate numb and take the SQRT directly:

        sqroot _ SQRT (CVD(INCHWL));

At first you might think that we could go a step further to

        PRINT ("ANS: ",SQRT(CVD(INCHWL)));

and we could as far as the Sail syntax is concerned but it would produce
a bug  in our program.   We would  be printing out  "ANS: "  right after
"Type number: "  before the user would  have time to even  start typing.
But we have considerably simplified our program to:

        BEGIN
        REAL sqroot;
        PRINT ("Type number: ");
        sqroot _ SQRT (CVD(INCHWL));
        PRINT ("ANS: ",sqroot);
        END;

Remember that intermediate results do  not need to be stored  unless you
will need them again later  for something else.  By not  storing results
unnecessarily, you save the  extra assignment statement and  the storage
space by not needing to declare a variable for temporary storage.



2.3.4  IF...THEN Statement

The  previous example  included no  error checking.   There  are several
fundamental  programming  tasks that  cannot  be handled  with  just the
assignment  and  PRINT  statements such  as  1)  conditional  tasks like
checking  the value  of a  number (is  it negative?)  and  taking action
according to the result of the test and 2) looping or iterative tasks so
that we  could go back  to the  beginning and ask  the user  for another
number to  be processed.  These  sorts of functions  are performed  by a
group of statements called control statements.  In this section  we will
cover the  IF..THEN statement for  conditionals.  More  advanced control
statements will be discussed in Section 2.6.

There are two kinds of IF...THEN statements:

        IF boolean expression THEN statement


        IF boolean expression THEN statement
                              ELSE statement

A boolean  expression is  an expression  whose value  is either  true or
false.  A wide  variety of expressions can  effectively be used  in this
position.  Any arithmetic expression can be a boolean; if its value  = 0
then it is  FALSE.  For any  other value, it is  TRUE.  For now  we will
just consider the following three cases:

        1)  BOOLEAN variables (where errorsw, base8, and miniVersion
    are declared as BOOLEANs):

        IF errorsw THEN
           PRINT("There's been an error.") ;
        IF base8 THEN digits  "01234567"
                    ELSE digits _ "0123456789" ;
        IF miniVersion THEN counter  10
                          ELSE counter _ 100;

        2)  Expressions with relational operators such as EQU, =, <,
    >, LEQ, NEQ, and GEQ:

        IF x < currentSmallest THEN
                       currentSmallest _ x;
        IF divisor NEQ 0 THEN
                       quotient_dividend/divisor;
        IF i GEQ 0 THEN ii+1 ELSE ii-1;

        3)  Complex  expressions formed  with the  logical operators
    AND, OR, and NOT:

        IF NOT errorsw THEN
            answers[counter] _ quotient;
        IF x<0 OR y<0 THEN
            PRINT("Negative numbers not allowed.")
            ELSE z _ SQRT(x)+SQRT(y);

In the IF..THEN statement,  the boolean expression is evaluated.   If it
is  true then  the statement  following the  THEN is  executed.   If the
boolean expression  is false  and the particular  statement has  no ELSE
part then nothing is done.  If the boolean is false and there is an ELSE
part then the statement following the ELSE will be executed.

    BEGIN BOOLEAN bool; INTEGER i,j;
    bool_TRUE;  i_1;  j_1;
    IF bool THEN i_i+1;     COMMENT i=2 AND j=1;
    IF bool THEN i_i+1 ELSE j_j+1;
                            COMMENT i=3 AND j=1;
    bool_false;
    IF bool THEN i_i+1;     COMMENT i=3 AND j=1;
    IF bool THEN i_i+1 ELSE j_j+1;
                            COMMENT i=3 AND j=2;
    END;

It is  VERY IMPORTANT  to note  that NO  semi-colon appears  between the
statement  and   the  ELSE.   Semi-colons   are  used  a)   to  separate
declarations from each other, b) to separate the final  declaration from
the first statement  in the block, c)  to separate statements  from each
other, and d) to  mark the end of a  comment.  The key point to  note is


that semi-colons  are used to  separate and NOT  to terminate.   In some
cases it doesn't hurt to put  a semi-colon where it is not  needed.  For
example,  no semi-colon  is needed  at  the end  of the  program  but it
doesn't hurt.  However, the format

    IF expression THEN statement ; ELSE statement ;

makes it difficult for the compiler to understand your code.   The first
semi-colon  marks  the  end  of what  could  be  a  legitimate IF...THEN
statement and it will be taken as such.  Then the compiler is faced with

    ELSE statement ;

which is meaningless and will produce an error message.

The following is a part of a sample program which uses several IF...THEN
statements:

    BEGIN BOOLEAN verbosesw;  STRING reply;

    PRINT("Verbose mode?  (Type Y or N): ");
    reply _ INCHWL;   COMMENT   INTTY for TENEX;

    IF reply="Y" OR reply="y" THEN verbosesw _ TRUE
    ELSE
    IF reply="N" OR reply="n" THEN verbosesw_FALSE;

    IF verbosesw THEN PRINT("-long msg-")
    ELSE PRINT("-short msg-");

    COMMENT now all our messages printed out to
    terminal will be conditional on verbosesw;
    END;

There  are two  interesting points  to note  about this  sample program.
First is the use of = rather than EQU to check the user's reply.  EQU is
used to check the equality of variables of type STRING and = is  used to
check the  equality of variables  of type INTEGER  or REAL.  If  we were
asking the user for a full word answer like "yes" or "no" instead of the
single character  then we  would need the  EQU to  check what  the input
string  was.   However,  in  this  case  where  we  only  have  a single
character,  we can  use the  fact that  when a  string (either  a string
variable or a  string constant) is put  someplace in a program  where an
integer  is expected  then Sail  automatically converts  to  the integer
which is  the ASCII  code for the  FIRST character  in the  string.  For
example, in the environment

    STRING str;   str _ "A";

all of the following are true:

        "A" = str = 65 = '101
        "A" NEQ "a"
        str NEQ "a"
        str + 1 = "A" + 1 = '102 = "B"
        str = "Aardvark"
        NOT EQU(str,"Aardvark")

('101 is an octal integer constant.)


When  you  are  dealing  with  single  character  strings  (or  are only
interested in the first character  of a string) then you can  treat them
like  integers and  use  the arithmetic  operators like  the  = operator
rather than EQU.  In general (over 90% of the time), EQU is slower.

A second point to  note in the above IF...THEN  example is the use  of a
nested IF...THEN.  The statements following the THEN and the ELSE may be
any  kind  of  statement  including  another  IF..THEN  statement.   For
example,

    IF upperOnly THEN letters _ "ABC"
       ELSE IF lowerOnly THEN letters _ "abc"
       ELSE letters _ "ABCabc";

This  is  a very  common  construction when  you  have a  small  list of
possibilities to check for.  (Note: if there are a large number of cases
to   be   checked   use  the   CASE   statement   instead.)  The  nested
IF..THEN..ELSE statements  save a  lot of  processing if  used properly.
For example, without the nesting this would be:

IF upperOnly THEN letters _ "ABC";
IF lowerOnly THEN letters _ "abc";
IF NOT upperOnly AND NOT lowerOnly THEN
        letters _ "ABCabc";

Regardless  of  the  values  of  upperOnly  and  lowerOnly,  the boolean
expressions in the three IF..THEN statements need to be checked.  In the
nested  version,  if upperOnly  is  TRUE then  lowerOnly  will  never be
checked.  For greatest  efficiency, the most  likely case should  be the
first one tested in a  nested IF...THEN statement.  If that  likely case
is true, no further testing will be done.

To avoid  ambiguity in parsing  the nested  IF..THEN..ELSE construction,
the  following  rule  is  used:  Each  ELSE  matches  up  with  the last
unmatched THEN.  So that

    IF exp1 THEN   IF exp2 THEN s1 ELSE s2 ;

will group the ELSE with the second THEN which is equivalent to

    IF exp1 THEN
        BEGIN
            IF exp2 THEN s1 ELSE s2;
        END;

and also equivalent to

    IF exp1 AND exp2 THEN s1;
    IF exp1 AND NOT exp2 THEN s2;  .

You can change the structure with BEGIN/END to:

    IF exp1 THEN
        BEGIN
            IF exp2 THEN s1
        END ELSE s2 ;

which is equivalent to

    IF exp1 AND exp2 THEN s1;


    IF NOT exp1 THEN s2;

There is another  common use of  BEGIN/END in IF..THEN  statements.  All
the examples so far have shown a single simple statement to be executed.
In fact, you often will have a variety of tasks to perform based  on the
condition tested  for.  For example,  before you make  an entry  into an
array, you may want to check that you are within the array bounds and if
so then both make the entry and increment the pointer so that it will be
ready for the next entry:

    IF pointer LEQ max THEN
        BEGIN
             data[pointer] _ newEntry;
             pointer_pointer + 1;
        END
    ELSE PRINT("Array DATA is already full.");

Here we see  the use of a  compound statement.  Compound  statements are
exactly like  blocks except  that they have  no declarations.   It would
also be perfectly acceptable to use a block with declarations  where the
compound  statement is  used  here.  In  fact both  blocks  and compound
statements  ARE statements  and  can be  used  ANY place  that  a simple
statement can be used.  All of the statements between BEGIN and  END are
executed as a unit (unless one of the statements itself causes  the flow
of execution to be changed).



2.4  Expressions

We  have  already  seen  many  of  the  operators  used  in expressions.
Sections 4 and 8  of the Sail manual  cover the operators, the  order of
evaluation  of expressions,  and type  conversions.  Appendix  1  of the
manual gives  the word equivalents  for the single  character operators,
e.g., LEQ  for the less-than-or-equal-to  sign, which are  not available
except  at  SU-AI.  You  should  read these  sections  especially  for a
complete list  of the  arithmetic and  boolean operators  available (the
string operators  will be  covered shortly in  this TUTORIAL).   A short
discussion of type  conversion will be given  later in this  section but
you should  also read  these sections  in the  Sail manual  for complete
details on type conversions.

There  are  three  kinds  of expressions  that  we  have  not  used yet:
assignment, conditional, and case expressions.  These are much  like the
statements of the same names.

2.4.1  Assignment Expressions

Anywhere that you can have an expression, you may at the same  time make
an assignment.  The  value will be used  as the value of  the expression
and also assigned to the given variable.  For example:

    IF (reply_INCHWL) = "?" THEN ....
    COMMENT inputs reply and makes first test
            on it in single step;

    IF (counter_counter+1) > maxEntry THEN ....
    COMMENT updates counter and checks it for
            overflow in one step;


    counter_ptr_nextloc_0;
    COMMENT initializes several variables to 0
            in one statement;

    arry[ptr_ptr+1] _ newEntry ;
    COMMENT updates ptr & fills next array
            slot in single step;

Note that  the assignment operator  has low precedence  and so  you will
often need to use parenthesizing to get the proper order  of evaluation.
This is an area where many coding errors commonly occur.

    IF i_j OR boole THEN ....

is parsed like

    IF i_(j OR boole) THEN ....

rather than

    IF (i_j) OR boole THEN ....

See the sections in the Sail manual referenced above for a more complete
discussion of the order of evaluation in expressions.  In general  it is
the  normal  order  for  the  arithmetic  operators;  then  the  logical
operators  AND and  OR (so  that  OR has  the lowest  precedence  of any
operator except  the assignment  operator); and left  to right  order is
used for two operators at the same level (but the manual  gives examples
of exceptions).  You can  use parentheses anywhere to specify  the order
that you want.  As an example of the effect of left-to-right evaluation,
note that

        indexer_2;
        arry[indexer]_(indexer_indexer+1);

will put  the value  3 in  arry[2], since  the destination  is evaluated
before indexer is incremented.

A word of caution is needed about assignment expressions.  Make  sure if
you put an ordinary assignment in an expression that that  expression is
in a position where it will ALWAYS be evaluated.  Of course,

        IF i<j THEN i_i+1;

will not always increment i  but this is the intended  result.  However,
the following is unintended and incorrect:

        IF verbosesw THEN
        PRINT("The square root of ",numb," is ",
              sqroot_SQRT(numb)," .")
        ELSE PRINT(sqroot) ;

If  verbosesw  =  FALSE,  the  THEN  portion  is  not  executed  and the
assignment  to  sqroot is  not  made.   Thus sqroot  will  not  have the
appropriate  value  when  it  is PRINTed.   Assigning  the  result  of a
computation  to  a  variable  to save  recomputing  it  is  an excellent
practice but be careful where you put the assignment.

Another very  bad place for  assignment expressions is  following either


the  AND  or  OR  logical  operators.   The  compiler  handles  these by
performing as little evaluation as possible so in

        exp1 OR exp2

the  compiler  will first  evaluate  exp1 and  if  it is  TRUE  then the
compiler knows that  the entire boolean  expression is true  and doesn't
bother to evaluate exp2.  Any assignments in exp2 will not be made since
exp2 is not evaluated.  (Of course,  if exp1 is FALSE then exp2  will be
evaluated.)  Similarly for

        exp1 AND exp2

if exp1  is FALSE then  the compiler knows  the whole  AND-expression is
FALSE and doesn't bother evaluating exp2.

As with nested IF...THEN...ELSE statements, it is a good coding practice
to choose  the order  of the expressions  carefully to  save processing.
The most likely expression should  be first in an OR expression  and the
least likely first in an AND expression.



2.4.2  Conditional Expressions

Conditionals can also be used  in expressions.  These have a  more rigid
structure than conditional statements.  It must be

    IF boolean expression THEN exp1 ELSE exp2

where the ELSE is not optional.

N. B.  The  type of a  conditional expression is  the type of  exp1.  If
exp2  is evaluated,  it will  be  converted to  the type  of  exp1.  (At
compile time it is not known which will be used so an arbitrary decision
is  made  by  always  using  the  type  of  exp1.)  Thus  the statement,
xIF flag THEN 2 ELSE y; , will always assign an INTEGER to x.  If x and
y are REALs then  y is converted to  INTEGER and then converted  to REAL
for the assignment to x.  XIF flag THEN 2 ELSE 3.5;  will assign either
2.0 or 3.0 to x (assuming x is REAL).  Examples are:

    REAL ARRAY results
               [1:IF miniversion THEN 10 ELSE 100];

    PRINT (IF found THEN words[i]
                    ELSE "Word not found.");
    COMMENT words[i] must be a string;

    profit _ IF (net _ income-cost) > 0 THEN net
             ELSE 0;

These conditional expressions will often need to be parenthesized.


2.4.3  CASE Expressions

CASE   statements  are   described   in  Section   2.6.4   below.   CASE
expressions are also allowed with the format:

    CASE integer OF (exp0,exp1,...,expN)

where the first case is always  0.  This takes the value you  give which
must be an integer between 0 and N and uses the corresponding expression
from the list.  A frequent use is for error handling where each error is
assigned  a number  and the  number of  the current  error is  put  in a
variable.  Then a statement like the following can be used to  print the
proper error message:

    PRINT(CASE errno OF
               ("Zero division attempted",
                "No negative numbers allowed",
                "Input not a number"));

Remember  that errno  here must  range from  0 to  2; otherwise,  a case
overflow occurs.



2.4.4  String Operators

The STRING operators are:

    EQU       Test for string equality:
              s_"ABC"; t_"abc";  test_EQU(s,t);
              RESULT:  test = FALSE .

    &         Concatenate two strings together:
              s_"abc"; t_"def"; u_s&t;
              RESULT:  EQU(u,"abcdef") = TRUE .

    LENGTH    Returns the length of a string:
              s_"abc"; i_LENGTH(s);
              RESULT:  i = 3 .

    LOP       Removes the first char in a string
              and returns it:
              s_"abc"; t_LOP(s);
              RESULT:  (EQU(s,"bc") AND
                        EQU(t,"a")) = TRUE .

Although LENGTH and LOP look like procedures syntactially, they actually
compile code "in-line".   This means that  they compile very  fast code.
However, one  unfortunate side-effect is  that LOP cannot  be used  as a
statement, i.e., you cannot say  LOP(s); if you just want to  throw away
the first character of the string.  You must always either use or assign
the character returned  by LOP even if  you don't want it  for anything,
e.g.,  junkLOP(s); .   Another  point  to note  about  LOP  is  that it
actually removes the  character from the  original string.  If  you will
need the intact string  again, you should make  a copy of it  before you
start LOP'ing, e.g., tempCopys; .

A little background on the implementation of strings should help  you to
use  them  more  efficiently.   Inefficient  use  of  strings  can  be a


significant  inefficiency in  your programs.   Sail sets  up an  area of
memory called string space where all the actual strings are stored.  The
runtime system increases the size of this area dynamically as  it begins
to become full.  The runtime system also performs garbage collections to
retrieve space taken  by strings that are  no longer needed so  that the
space can be reused.  The text of the strings is stored in string space.
Nothing  is put  in string  space until  you actually  specify  what the
string is to be, i.e., by  an assignment statement.  At the time  of the
declaration, nothing is put in string space.  Instead the  compiler sets
up a 2-word string descriptor for each string declared.  The  first word
contains  in its  left-half an  indication of  whether the  string  is a
constant or a variable and  in its right-half the length of  the string.
The second word is  a byte pointer to the  location of the start  of the
string in string space.  At the time of the declaration, the length will
be zero and the byte pointer word will be empty since the string  is not
yet in string space.

From this we can see that LENGTH and LOP are very  efficient operations.
LENGTH picks up the length from the descriptor word; and  LOP decrements
the length by 1, picks up the character designated by the  byte pointer,
and increments the byte pointer.  LOP does not need to do  anything with
string  space.  Concatenations  with  & are  however  fairly inefficient
since  in general  new strings  must be  created.  For  s & t,  there is
usually no way to  change the descriptor words  to come up with  the new
string (unless s and t  are already adjacent in string  space).  Instead
both s  and t  must be  copied into a  new string  in string  space.  In
general since the pointer is kept to the beginning of the string,  it is
less expensive  to look  at the beginning  than the  end.  On  the other
hand, when concatenating, it is better to keep building onto the  end of
a given  string rather  than the beginning.   The runtime  routines know
what is at the end of string space and, if you happen to  concatenate to
the end of the last string put in, the routines can do  that efficiently
without needing to copy the last string.

Assigning one string variable  to another, e.g., for making  a temporary
copy of the string, is also fast since the string descriptor rather than
the text is copied.

These  are  general  guidelines  rather  than  strict  rules.  Different
programs will have different specific needs and features.



2.4.5  Substrings

Sail  provides a  way of  dealing with  selected subportions  of strings
called  substrings.   There  are two  different  ways  to  designate the
desired substring:

        s[i TO j]
        s[i FOR j]

where [i TO j] means the substring starting at the ith character  in the
string through the jth character and [i FOR j] is the substring starting
at the ith  character that is j  characters long.  The  numbering starts
with 1 at the first character  on the left.  The special symbol  INF can
be used to  refer to the last  character (the rightmost) in  the string.
So, s[INF FOR 1] is the last  character; and s[7 TO INF] is all  but the
first six characters.   If you are using  a substring of a  string array
element then the format is arry[index][i TO j].


Suppose you have made the assignment s  "abcdef" .  Then,

    s[1 TO 3]                   is  "abc"
    s[2 FOR 3]                  is  "bcd"
    s[1 TO INF]                 is  "abcdef"
    s[INF-1 TO INF]             is  "ef"
    s[1 TO 3]&"X"&s[4 TO INF]   is  "abcXdef"  .

Since substrings are parts of the text of their source strings, it  is a
very cheap operation to break a string down, but is fairly  expensive to
build up a new string out of substrings.



2.4.6  Type Conversions

If you use  an expression of one  type where another type  was expected,
then automatic type conversion is performed.  For example,

        INTEGER i;
        i _ SQRT(5);

will  cause 5  to be  converted  to real  (because SQRT  expects  a real
argument) and the square root of 5.0 to be automatically converted to an
integer before  it is  assigned to i  which was  declared as  an integer
variable and can only have  integer values.  As noted in Section  4.2 of
the Sail manual, this conversion is done by truncating the real value.

Another example of automatic type  conversion that we have used  here in
many of the sample programs is:

        IF reply = "Y" THEN .....

where the  = operator  always expects integer  or real  arguments rather
than  strings.  Both  the value  of the  string variable  reply  and the
string  constant "Y"  will  be converted  to integer  values  before the
equality  test.   The  manual  shows  that  this  conversion, string-to-
integer, is performed  by taking the first  character of the  string and
using its ASCII value.   Similarly converting from integer to  string is
done by interpreting the integer (or just the rightmost seven bits if it
is less than 0 or it is too large--that is any number over 127  or '177)
as an ASCII code and using the character that the code represents as the
string.  So, for example,

        STRING s;
        s _ '101 & '102 & '103;

will make the string "ABC".

The  other common  conversions  that we  have seen  are  integer/real to
boolean and string to boolean.  Integers and reals are true if non-zero;
strings are true if they have a non-zero length and the  first character
of the string is not the NUL character (which is ASCII code 0).

You  may  also  call  one of  the  built-in  type  conversion procedures
explicitly.  We have used CVD extensively to convert  strings containing
digits to  the integer  number which  the digits  represent.  CVD  and a
number  of  other useful  type  conversion procedures  are  described in
Section  8.1  of  the  Sail manual.   Also  this  section  discusses the


SETFORMAT procedure which is  used for specifying the number  of leading
zeroes and the  maximum length of the  decimal portion of the  real when
printing.   SETFORMAT  is extremely  useful  if you  will  be outputting
numbers  as  tables  and  need  to  have  them  automatically   line  up
vertically.



2.5  Scope of Blocks

So far we have  seen basically only one  use of inner blocks.   With the
IF..THEN statement, we saw that you sometimes need a block rather than a
simple  statement  following  the  THEN  or  ELSE  so  that  a  group of
statements can be executed as a unit.

In fact, blocks can  be used within the  program any place that  you can
use  a  single  statement.   Syntactically,  blocks  are  statements.  A
typical program might look like this:

    BEGIN "prog"
      .
      .
        BEGIN "initialization"
          .
          .
        END "initialization"

        BEGIN "main part"

            BEGIN "process data"
              .
              .
                BEGIN "output results"
                  .
                  .
                END "output results"

            END "process data"
          .
          .
        END "main part"

        BEGIN "finish up"
          .
          .
        END "finish up"

    END "prog"

The declarations  in each  block establish variables  which can  only be
used in the given block.  So another reason for using inner blocks is to
manage variables needed for a specific short range task.

Each block can (should) have a block name.  The name is given  in quotes
following the  BEGIN and  END of the  block.  The  case of  the letters,
number of spaces,  etc. are important (as  in string constants)  so that
the names "MAIN LOOP", "Main Loop", "main loop", and "Main loop" are all
different and  will not  match.  There are  several advantages  to using
block names: your programs are easier to read, the names will be used by


the debugger and thus will make debugging easier, and the  compiler will
check block names and report any mismatches to help you pinpoint missing
END's (a very common programming error).

The above  example shows  us how blocks  may nest.   Any block  which is
completely within  the scope of  another block is  said to be  nested in
that block.  In any program, all  of the inner blocks are nested  in the
outer  block.  Here,  in addition  to all  the blocks  being  within the
"prog" block, we find "output results" nested in "process data" and both
"output results" and  "process data" nested  in "main part".   The three
blocks  called "initialization",  "main part"  and "finish  up"  are not
nested with relation to each other but are said to be at the same level.
None of the variables declared in any of these three blocks is available
to any  of the  others.  In  order to  have a  variable shared  by these
blocks, we  need to declare  it in a  block which is  "outer" to  all of
them, which is in this case the very outermost block "prog".

Variables are available in the  block in which they are declared  and in
all the blocks nested  in that block UNLESS  the inner block also  has a
variable of the  same name declared (a  very bad idea in  general).  The
portion  of the  program, i.e.,  the blocks,  in which  the  variable is
available is called the scope of the variable.

    BEGIN "main"
    INTEGER i, j;
    i_5;
    j_2;
    PRINT("CASE A: i=",i,"   j=",j);
      BEGIN "inner"
        INTEGER i, k;
        i_10;
        k_3;
        PRINT("CASE B: i=",i,"   j=",j,"   k=",k);
        j_4;
      END "inner" ;
    PRINT("CASE C: i=",i,"   j=",j);
    END "main"

Here we cannot access k except in block "inner".  The variable j  is the
same throughout the entire program.  There are 2 variables both named i.
So the program will print out:

    CASE A: i=5   j=2
    CASE B: i=10   j=2   k=3
    CASE C: i=5   j=4

Variables are referred to as local variables in the block in  which they
are declared.  They  are called global variables  in relation to  any of
the blocks nested in the block of their declaration.  With both  a local
and  a  global variable  of  the  same name,  the  local  variable takes
precedence.  There are three relationships that a variable can have to a
block:

       1)  It  is  inaccessible  to  the  block  if  the  variable is
   declared in a block at the same level as the given block or  it is
   declared in a block nested within the given block.

       2)  It is local to the block if it is declared in the block.


       3)  It is global to the block if it is declared in one  of the
   blocks that the given block is nested within.


Often  the term  "global  variables" is  used specifically  to  mean the
variables declared in the outer block which are global to all  the other
blocks.

In  reading  the  Sail  manual,  you  will  see  the  terms: allocation,
deallocation, initialization, and reinitialization.  It is not important
to completely understand the implementation details, but it is extremely
important to understand the  effects.  The key point is  that allocating
storage for data can be handled in one of two ways.   Storage allocation
refers to the actual setting  up of data locations in memory.   This can
be done 1) at compile time or  2) at runtime.  If it is done  at runtime
then we  say that the  allocation is dynamic.   Basically, it  is arrays
which are dynamically allocated (excluding outer block arrays  and other
arrays which are  declared as OWN).  LISTS,  SETS, and RECORDS  which we
have not discussed in this section are also allocated  dynamically.  The
following  are allocated  at compile  time and  are NOT  dynamic: scalar
variables (INTEGER,  BOOLEAN, REAL and  STRING) except where  the scalar
variable is in a recursive procedure, outer block arrays, and  other OWN
arrays.   ALGOL  users  should  note  this  as  an  important ALGOL/Sail
difference.

Dynamic  storage (inner  block arrays,  etc.) will  be allocated  at the
point  that the  block  is entered  and  deallocated when  the  block is
exited.  This makes for quite efficient use of large amounts  of storage
space that serve a short term need.  Also, it allows you to set variable
size bounds for these arrays since  the value does not need to  be known
at compile time.

At the  time that storage  is allocated, it  is also  initialized.  This
means that the  initial value is assigned---NULL  for strings and  0 for
integers, reals, and booleans.  Since arrays are allocated each time the
block is  entered, they are  reinitialized each time.   We have  not yet
seen any cases where the same block is executed more than once  but this
is very frequent with the iterative and looping control statements.

Scalar variables and outer  block arrays are not  dynamically allocated.
They are allocated by the  compiler and will receive the inital  null or
zero  value  when  the  program  is  loaded  but  they  will   never  be
reinitialized.  While you  are not in the  block, the variables  are not
accessible to  you but they  are not deallocated  so they will  have the
same value when you enter the block the next time as when you  exited it
on the previous use.   Usually you will find  that this is not  what you
want.   You  should  initialize  all  local  scalar  variables  yourself
somewhere near the start of the block--usually to NULL for strings and 0
for arithmetic  variables unless  you need  some other  specific initial
value.  You should also  initialize all global scalars (and  outer block
arrays) at the start of your  program to be on the safe side.   They are
initialized for you  when the compiled program  is later run,  but their
values  will not  be  reinitialized if  the program  is  restarted while
already in core and the results will be very strange.

One exception is  the blocks in RECURSIVE  PROCEDUREs which do  have all
non-OWN variables  properly handled and  initialized as  recursive calls
are made on the blocks.

If you should want to clear an array, the command


    ARRCLR(arry)

will clear arry  (set string arrays to  NULL and arithmetic to  0).  For
arithmetic (NOT string) arrays,

    ARRCLR(arry,val)

will set the elements of arry to val.

See Sections  2.2-2.4 of the  Sail manual for  more information  on OWN,
SAFE, and PRELOADED  arrays and Section 8.5  for the ARRBLT  and ARRTRAN
routines for moving the contents of arrays.



2.6  More Control Statements

2.6.1  FOR Statement

The FOR  statement is used  for a definite  number of  iterations.  Many
times you will  want to repeat certain  code a specific number  of times
(where  usually  the  number  in the  sequence  of  repetitions  is also
important in the code performed).  For example,

    FOR i _ 1 STEP 1 UNTIL 5 DO
        PRINT(i, "  ", SQRT(i));

which will print out a table of the square roots of the numbers 1 to 5.

The syntax of the (simple) FOR statement is

    FOR variable _ starting-value STEP increment
        UNTIL end-value DO statement

The  iteration variable  is assigned  the starting-value  and  tested to
check if it exceeds  the end-value; if it  is within the range  then the
statement  after the  DO  is executed  (otherwise the  FOR  statement is
finished).  This completes the first execution of the FOR-loop.

Next the increment is added to  the variable and it is tested to  see if
it now  exceeds the  end-value.  If it  does then  the statement  is not
executed again and the FOR  statement is finished.  If it is  within the
maximum (or equal  to it) then the  statement is executed again  but all
instances of the iteration variable  in the statement will now  have the
new  value.   This  incrementing  and  checking  and  executing  loop is
repeated until the iteration variable exceeds the end-value.

For those users familar  with GOTO statements and LABELs,  the following
two program fragments for computing ans  FACT(n) are equivalent.

    ans _ 1;
    FOR i _ 2 STEP 1 UNTIL n DO  ans _ ans * i;

is equivalent to:



             ans _ 1;
             i _ 2;
    loop:    IF i > n THEN GOTO beyond;
             ans _ ans * i;
             i _ i + 1;
             GOTO loop;
    beyond:

There  is  considerable  dispute  on whether  or  not  the  use  of GOTO
statements should be encouraged and if so under what  conditions.  These
statements  are available  in Sail  but will  not be  discussed  in this
Tutorial.

Very often FOR-loops are used for indexing through arrays.  For example,
if you  are computing averages,  you will need  to add  together numbers
which  might be  stored in  an array.   The following  program  allows a
teacher to  input the  total number  of tests  taken and  a list  of the
scores; then the program returns the average score.

    BEGIN "averager"
    REAL average; INTEGER numbTests, total;
    average_numbTests_total_0;
    COMMENT remember to initialize variables;
    PRINT("Total number of tests: ");
    numbTests_CVD(INCHWL);
      BEGIN "useArray"
        INTEGER ARRAY testScores[1:numbTests];
        COMMENT array has variable bounds so must
                be in inner block;
        INTEGER i;
        COMMENT for use as the iteration variable;

        FOR i _ 1 STEP 1 UNTIL numbTests DO
            BEGIN "fillarray"
                PRINT("Test Score #",i," : ");
                testScores[i] _ CVD(INCHWL);
            END "fillarray";

        FOR i _ 1 STEP 1 UNTIL numbTests DO
            total_total+testScores[i];
        COMMENT note that total was initialized to
                0 above;

        END "useArray";

    IF numbTests neq 0 THEN average_total/numbTests;
    PRINT("The average is ",average,".");
    END "averager";

In the first FOR-loop, we see  that i is used in the PRINT  statement to
tell the user which  test score is wanted then  it is used again  as the
array subscript  to put the  score into the  i'th element of  the array.
Similarly it is used in the  second FOR-loop to add the i'th  element to
the cumulative total.

The iteration variable, start-value, increment, and end-value can all be
reals as well as integers. They can also be negatives (in which case the
maximum is  taken as  a minimum).  See  the Sail  manual for  details on


other variations  where multiple  values can be  given for  more complex
statements (these aren't used often).  One point to note is that in Sail
the end-value expression is evaluated each time through the  loop, while
the  increment value  is evaluated  only  at the  beginning if  it  is a
complex expression, as opposed to a constant or a simple variable.  This
means that  for efficiency,  if your  loop will  be performed  very many
times you should not have very complicated expressions in  the end-value
position.  If you need to  compute the end-value, do it before  the FOR-
loop and assign the value to a variable that can be used in the FOR-loop
to save having to recompute the value each time.  This doesn't save much
and probably isn't worth it for  5 or 10 iterations but for 500  or 1000
it can be quite a savings.  For example use:

    max_(ptr-offset)/2;
    FOR i_offset STEP 1 UNTIL max DO s ;

rather than

    FOR i_offset STEP 1 UNTIL (ptr-offset)/2 DO s;




2.6.2  WHILE...DO Statement and DO...UNTIL Statement

Often you  will want to  repeat code  but not know  in advance  how many
times.  Instead the iteration will be finished when a  certain condition
is met.  This is called  indefinite iteration and is done with  either a
WHILE...DO or a DO...UNTIL statement.

The syntax of WHILE statements is:

    WHILE  boolean-expression  DO  statement

The  boolean is  checked and  if  FALSE nothing  is done.   If  TRUE the
statement is executed and then the boolean is checked again, etc.

For example, suppose we want to check through the elements of an integer
array until we find an element containing a given number n:

    INTEGER ARRAY arry[1:max];
    ptr _ 1;
    WHILE (arry[ptr] NEQ n) AND (ptr < max)  DO
        ptr_ptr+1;

If the array element  currently pointed to by  ptr is the number  we are
looking for OR if  the ptr is at the  upper bound of the array  then the
WHILE statement is finished.   Otherwise the ptr is incremented  and the
boolean  (now  using  the  next element)  is  checked  again.   When the
WHILE...DO statement  is finished,  either ptr will  point to  the array
element with the number or ptr=max will mean that nothing was found.

The  WHILE...DO statement  is equivalent  to the  following  format with
LABELs and the GOTO statement:

    loop:   IF NOT boolean expression THEN
                   GOTO beyond;
            statement;
            GOTO loop;
    beyond:


The DO...UNTIL statement is very similar except that 1) the statement is
always executed the  first time and then  the check is made  before each
subsequent  loop through  and 2)  the loop  continues UNTIL  the boolean
becomes true rather than WHILE it is true.

    DO  statement  UNTIL  boolean-expression

For example, suppose we want to get a series of names from the  user and
store the names in a  string array.  We will finish inputting  the names
when the user types a bare carriage-return (which results in a string of
length 0 from INCHWL or INTTY).

    i_0;
    DO   PRINT("Name #",i_i+1," is: ")
            UNTIL   (LENGTH(names[i]_INCHWL) = 0 );


The equivalent  of the  DO...UNTIL statement using  LABELs and  the GOTO
statement is:

  loop:   statement;
          IF NOT boolean expression THEN GOTO loop;

Note that the checks in the WHILE...DO and DO...UNTIL statements are the
reverse of each other.   WHILE...DO continues as long as  the expression
is true but DO...UNTIL continues as long as the expression is  NOT true.
So that

        WHILE i < 100 DO .....

is equivalent to


        DO ..... UNTIL i GEQ 100

except that  the statement is  guaranteed to be  executed at  least once
with the DO...UNTIL but not with the WHILE...DO.

The WHILE and DO  statements can be used,  for example, to check  that a
string which  we have  input from the  user is  really an  integer.  CVD
stops converting if it hits  a non-digit and returns the results  of the
conversion to that point but does not give an error indication so that a
check of  this sort should  probably be done  on numbers input  from the
user before CVD is called.

    INTEGER numb, char;
    STRING reply,temp; BOOLEAN error;
    PRINT("Type the number: ");
    DO
      BEGIN
        error_FALSE;
        temp_reply_INCHWL;
        WHILE LENGTH(temp) DO
          IF NOT ("0" LEQ (char_LOP(temp)) LEQ "9")
            THEN error_TRUE;
        IF error THEN PRINT("Oops, try again: ");
      END
      UNTIL NOT error;
    numb_CVD(reply);


2.6.3  DONE and CONTINUE Statements

Even with definite and indefinite iterations available, there will still
be times when you need a greater degree of control over the  loop.  This
is accomplished by the DONE and CONTINUE statements which can be used in
any loop which begins with DO, e.g.,

    FOR i 1 STEP 1 UNTIL j DO ...
    DO ... UNTIL exp
    WHILE exp DO ...

(See the  manual for  a discussion of  the NEXT  statement which  is not
often  used.)    DONE  means  to  abort  execution  of  the  entire FOR,
DO...UNTIL or WHILE...DO statement immediately.  CONTINUE means  to stop
executing the  current pass through  the loop and  continue to  the next
iteration.

Suppose a string array is being used as a "dictionary" to hold a list of
100 words and we want to look up one of the words which is now stored in
a string called target:

    FOR i _ 1 STEP 1 UNTIL 100 DO
        IF EQU(words[i],target) THEN DONE;
    IF i>100 THEN PRINT(target," not found.");

If the target is found, the FOR-loop will stop regardless of the current
value of i.  Note that  the iteration variable can be checked  after the
loop is terminated to determine whether the DONE forced  the termination
(i  LEQ 100)  or the  target  was never  found and  the  loop terminated
naturally (i > 100).

If  the  loops are  nested  then the  DONE  or CONTINUE  applies  to the
innermost loop unless  there are names on  the blocks to be  executed by
each loop and the name is given explicitly, e.g., DONE "someloop".  With
the DONE and CONTINUE statements,  we can now give the complete  code to
be used for the sample program given earlier where a number was accepted
from the user and the square root of the number was returned.  A variety
of error checks are made and the user can continue giving  numbers until
finished.   In this  example, block  names will  be used  with  DONE and
CONTINUE  only  where they  are  necessary for  the  correctness  of the
program; but use of block names everywhere is a good practice  for clear
programming.

  BEGIN "prog"    STRING temp,reply; INTEGER numb;

  WHILE TRUE DO
  COMMENT a very common construction which just
          loops until DONE;
    BEGIN "processnumb"
      PRINT("Type a number, <CR> to end, or ? :");
      WHILE TRUE DO
        BEGIN "checker"
          IF NOT LENGTH(temp_reply_INCHWL) THEN
              DONE "processnumb";
          IF reply = "?" THEN
            BEGIN
              PRINT("..helptext & reprompt..");
              CONTINUE;
              COMMENT defaults to "checker";
            END;


          WHILE LENGTH(temp) DO
            IF NOT ("0" LEQ LOP(temp) LEQ "9") THEN
              BEGIN
                PRINT("Oops, try again: ");
                CONTINUE "checker";
              END;
          IF (numb_CVD(reply)) < 0 THEN
            BEGIN
              PRINT("Negative, try again:  ");
              CONTINUE;
            END;
          DONE;
          COMMENT if all the checks have been
                  passed then done;
        END "checker";
      PRINT("The Square Root of ",numb," is ",
            SQRT(numb),".");
      COMMENT now we go back to top of loop
              for next input;
    END "processnumb";
  END "prog"




2.6.4  CASE Statement

The CASE statement is  similar to the CASE expression  where S0,S1,...Sn
represent the statements to be given at these positions.

    CASE integer OF
        BEGIN
        S0;
        ;   COMMENT the empty statement;
        S2;
         .
         .
        Sn
        END;

where ;'s are included for those  cases where no action is to  be taken.
Another version of the CASE statement is:


    CASE integer OF
        BEGIN
        [0] S0;
        [4] S4;  COMMENT cases can be skipped;
        [3] S3;  COMMENT need not be in order;
        [5] S5;
     [6][7] S6;  COMMENT may be same statement;
        [8] S8;
           .
           .
        [n] Sn
        END;

where explicit numbers in []'s are given for the cases to be included.


It is very IMPORTANT not  to use a semi-colon after the  final statement
before the END.  Also, do NOT  use CASE statements if you have  a sparse
number of cases spread over a wide range because the compiler  will make
a giant table, e.g.,

    CASE number OF
        BEGIN
        [0] S0;
        [1000] S1000;
        [2000] S2000
        END;

would produce a 2001 word table!

Remember that the  first case is  0 not 1.  An  example is using  a CASE
statement to process lettered options:

    INTEGER char;
    PRINT("Type A,B,C,D, or E : ");
    char_INCHWL;
    CASE char-"A" OF
    COMMENT "A"-"A" is 0, and is thus case 0;
        BEGIN
        <code for A option>;
        <code for B option>;
          .
          .
        <code for E option>
        END;



2.7  Procedures

We have been using built-in procedures and in fact would be lost without
them if we had  to do all our  own coding for the  arithmetic functions,
the  interactions with  the system  like Input/Output,  and  the general
utility  routines  that  simplify  our  programming.    Similarly,  good
programmers  would  be  lost  without the  ability  to  write  their own
procedures.  It takes a little time and practice getting into  the habit
of  looking  at programming  tasks  with an  eye  to  spotting potential
procedure components in the task, but it is well worth the effort.

Often  in programming,  the  same steps  must be  repeated  in different
places in the program.  Another way of looking at it is to say  that the
same task must be performed in  more than one context.  The way  this is
usually  handled  is to  write  a  procedure which  is  the  sequence of
statements that will perform the task.  This procedure itself appears in
the declaration portion of one of the blocks in your program and we will
discuss later the details of how you declare the procedure.  Essentially
at the time that you are writing the statement portion of  your program,
you can think of your procedures as black boxes.  You recognize that you
have  an  instance  of the  task  that  you have  designed  one  of your
procedures to perform and you include at that point in your  sequence of
statements a  procedure call statement.   The procedure will  be invoked
and will handle the task  for you.  In the simplest case,  the procedure
call is accomplished by just writing the procedure's name.

For example, suppose you have a calculator-type program that  accepts an


arithmetic  expression  from the  user  and evaluates  it.   At suitable
places  in  the  program you  will  have  checks to  make  sure  that no
divisions  by zero  are being  attempted.  You  might write  a procedure
called zeroDiv which prints out a message to the user saying that a zero
division has  occurred, repeats the  current arithmetic  expression, and
asks  if the  user would  like to  see the  prepared help  text  for the
program.   Every  time you  check  for zero  division  anyplace  in your
program and find it, you will call this procedure with the statement:

        zeroDiv;

and it will do everything it is supposed to do.

Sometimes  the general  format of  the task  will be  the same  but some
details will  be different.   These cases  can be  covered by  writing a
parameterized  procedure.  Suppose  that  we wanted  something  like our
zeroDiv procedure, but more general, that would handle a number of other
kinds  of errors.   It still  needs to  print out  a description  of the
error, the current expression being evaluated, and a suggestion that the
user consult  the help text;  but the description  of the error  will be
different depending on what the error was.  We accomplish this  by using
a variable when we write the procedure; in this case an integer variable
for the  error number.   The procedure  includes code  to print  out the
appropriate  message for  each error  number; and  the  integer variable
errno is  added to  the parameter list  of the  procedure.  Each  of the
parameters is a variable that will need to have a value  associated with
it automatically at the time the procedure is called.   (Actually arrays
and other procedures can also be parameters; but they will  be discussed
later.) We  won't worry  about the handling  of parameters  in procedure
declarations  now.  We  are concerned  with the  way the  parameters are
specified in the procedure  call.  Our procedure errorHandler  will have
one integer parameter so we call it with the expression to be associated
with  the  integer variable  errno  given in  parentheses  following the
procedure name in the procedure call.  For example,

       errorHandler(0)
       errorHandler(1)
       errorHandler(2)

would be  the valid calls  possible if we  had three  different possible
errors.

If there is more than one parameter, they are put in the order  given in
the declaration  and separated  by commas.   (Arguments is  another term
used  for  the actual  parameters  supplied in  a  procedure call.)  Any
expression  can  be  used  for the  parameter,  e.g.,  for  the built-in
procedure SQRT:

        SQRT(4)
        SQRT(numb)
        SQRT(CVD(INCHWL))
        SQRT(numb/divisor)


When Sail compiles the code for these procedure calls, it first includes
code to associate the appropriate values in the procedure call  with the
variables given in the  parameter list of the procedure  declaration and
then  includes the  code to  execute the  procedure.   When errorHandler
PRINTs the error message,  the variable errno will have  the appropriate


value associated with it.  This is not an assignment such as  those done
by the  assignment statement  and we  will also  be discussing  calls by
REFERENCE as well as  calls by VALUE; but we  don't need to go  into the
details  of the  actual  implementation --  see  the manual  if  you are
interested in how procedure  calls are implemented and  arguments pushed
on the stack.

Just as we often perform the same task many times in a given  program so
there  are  tasks  performed   frequently  in  many  programs   by  many
programmers.  The authors of  Sail have written procedures for  a number
of such  tasks which can  be used by  everyone.  These are  the built-in
procedures (CVD,  INCHWL, etc.)  and are actually  declared in  the Sail
runtime package so all that is needed for you to use them is placing the
procedure calls  at the appropriate  places.  Thus these  procedures are
indeed black boxes when they are used.

However, for our own procedures, we do need to write the code ourselves.
An example of a useful procedure is one which converts a string argument
to all uppercase characters.  First, the program with the procedure call
to upper  at the  appropriate place  and the  position marked  where the
procedure declaration will go:

    BEGIN
    STRING reply,name;
    ***procedure declaration here***

    PRINT("Type READ, WRITE, or SEARCH: ");
    reply upper(INCHWL);
    IF EQU(reply,"READ") THEN ....
        ELSE IF EQU(reply,"WRITE") THEN ....
        ELSE IF EQU(reply,"SEARCH") THEN ....
        ELSE .... ;
    END;

We put  the code for  the procedure right  in the  procedure declaration
which goes in the declaration  portion of any block.  Remember  that the
procedure must be declared in  a block which will make it  accessible to
the  blocks where  you are  going  to use  it; in  the same  way  that a
variable must be declared in the appropriate place.  Also, any variables
that appear in the code of the procedure must already be  declared (even
in the  declaration immediately preceding  the procedure  declaration is
fine).

Here is the procedure declaration for upper which should be  inserted at
the marked position in the above code:

    STRING PROCEDURE upper (STRING rawstring);
        BEGIN "upper"
        STRING tmp;  INTEGER char;
        tmp_NULL;
        WHILE LENGTH(rawstring) DO
            BEGIN
            char_LOP(rawstring);
            tmp_tmp&(IF "a" LEQ char LEQ "z"
                     THEN char-'40 ELSE char);
            END;
        RETURN(tmp);
        END "upper";

The syntax is:


    type-qualifier PROCEDURE  identifier ;
        statement

for procedures with no parameters OR


    type-qualifier PROCEDURE identifier
        ( parameter-list ) ; statement

where the parameter-list is  enclosed in ()'s and a  semi-colon precedes
the statement (which  is often called  the procedure body).   The <type-
qualifier>'s will be discussed shortly.

The parameter list  includes the names and  types of the  parameters and
must  NOT  have a  semi-colon  following  the final  item  on  the list.
Examples are:


    PROCEDURE offerHelp ;
    INTEGER PROCEDURE findWord
        (STRING target; STRING ARRAY words) ;
    SIMPLE PROCEDURE errorHandler
        (INTEGER errno) ;
    RECURSIVE INTEGER PROCEDURE factorial
        (INTEGER number) ;
    PROCEDURE sortEntries
        (INTEGER ptr,first; REAL ARRAY unsorted) ;
    STRING PROCEDURE upper (STRING rawString) ;

Each of these now needs a procedure body.

    PROCEDURE offerHelp ;

    BEGIN "offerHelp"
    COMMENT the procedure name is usually used
            as block name;
    PRINT("Would you like help (Y or N): ");
    IF upper(INCHWL) = "Y" THEN PRINT("..help..")
        ELSE RETURN;
    PRINT("Would you like more help (Y or N): ");
    IF upper(INCHWL) = "Y" THEN
        PRINT("..more help..");
    END "offerHelp";

This offers a brief  help text and if  it is rejected then  RETURNs from
the  procedure without  printing anything.   A RETURN  statement  may be
included in any procedure at any time.  Otherwise the brief help message
is  printed and  the  extended help  offered.  After  the  extended help
message is printed (or not printed), the procedure finishes  and returns
without needing  a specific  RETURN statement because  the code  for the
procedure  is over.   Note  that we  can  use procedure  calls  to other
procedures such  as upper provided  that we declare  them in  the proper
order with upper declared before offerHelp.

PROCEDURE declarations will usually have type-qualifiers.  There are two
kinds: 1) the  simple types--INTEGER, STRING,  BOOLEAN, and REAL  and 2)
the special ones--FORWARD, RECURSIVE, and SIMPLE.

FORWARD  is typically  used  if two  procedures call  each  other.  This


creates a problem because a procedure must be declared before it  can be
called.  For example, if  offerHelp called upper, and upper  also called
offerHelp then we would need:

    FORWARD STRING PROCEDURE upper
        (STRING rawstring) ;

    PROCEDURE offerHelp ;
      BEGIN "offerHelp"
        . . .
      <code for offerHelp including call to upper>
        . . .
      END "offerHelp";

    STRING PROCEDURE upper (STRING rawstring) ;
      BEGIN "upper"
        . . .
      <code for upper including call to offerHelp>
        . . .
      END "upper";

The FORWARD declaration does not  include the body but does  include the
parameter list  (if any).   This declaration  gives the  compiler enough
information about the  upper procedure for  it to process  the offerHelp
procedure.  FORWARD is also used  when there is no order  of declaration
of a series of procedures  such that every procedure is  declared before
it is used.  FORWARD declarations can sometimes be eliminated by putting
one of the procedures in the body of the other, which can be done if you
don't need to use both of them later.

RECURSIVE  is used  to qualify  the declaration  of any  procedure which
calls itself.  The  compiler will add  special handling of  variables so
that the  values of the  variables in the  block are preserved  when the
block is called again and  restored after the return from  the recursive
call.  For example,

    RECURSIVE INTEGER PROCEDURE factorial
        (INTEGER i);
    RETURN(IF i = 0 THEN 1 ELSE factorial(i-1)*i);

The compiler adds some overhead to procedures that can be omitted if you
do  not use  any  complicated structures.   Declaring  procedures SIMPLE
inhibits  the  addition of  this  overhead.  However,  there  are severe
restrictions  on SIMPLE  procedures;  and also,  BAIL can  be  used more
effectively  with  non-SIMPLE  procedures.  So  the  appropriate  use of
SIMPLE is during  the optimization stage (if  any) after the  program is
debugged.  At this time the SIMPLE qualifier can be added to  the short,
simple procedures  which will save  some overhead.  The  restrictions on
SIMPLE procedures are:

       1)  Cannot  allocate  storage  dynamically,  i.e.,  no non-OWN
   arrays can be declared in SIMPLE procedures.

       2)  Cannot  do  GO  TO's  outside  of  themselves  (the  GO TO
   statement has not been covered here).

       3)  Cannot, if declared inside other procedures, make  any use
   of the parameters of the other procedures.


Procedures which are declared as one of the simple types (REAL, INTEGER,
BOOLEAN, or STRING)  are called typed  procedures as opposed  to untyped
procedures (note that the SIMPLE, FORWARD, and RECURSIVE qualifiers have
no effect  on this  distinction).  Typed  procedures can  return values.
Thus typed procedures are like FORTRAN functions and  untyped procedures
are  like  FORTRAN  subroutines.    The  type  of  the   value  returned
corresponds to  the type  of the procedure  declaration.  Only  a single
value   may   be   returned   by   any   procedure.    The   format   is
RETURN( expression )  where   the  expression   is  enclosed   in  ()'s.
Procedure upper which was given above is a typed procedure which returns
as its value the uppercase version of the string.  Another example is:

    REAL PROCEDURE averager
        (INTEGER ARRAY scores; INTEGER max);
    BEGIN "averager"    REAL total;  INTEGER i;
    total _ 0;
    FOR i _ 1 STEP 1 UNTIL max DO
        total _ total + scores[i];
    IF max NEQ 0 THEN RETURN(total/max)
        ELSE RETURN(0);
    END "averager";

We might have a variety of calls to this procedure:

testAverage _ averager(testScores,numberScores);
salaryAverage _ averager(salaries,numberEmployees);
speedAverage _ averager(speeds,numberTrials);

where testScores, salaries, and speeds are all INTEGER ARRAYs.

Procedure calls can always be used as statements, e.g.,

    1)  IF divisor=0 THEN errorHandler(1);
    2)  offerHelp;
    3)  upper(text);

but as in  3) it makes  little sense to use  a procedure that  returns a
value as  a statement since  the value is  lost.  Thus  typed procedures
which return values can also be used as expressions, e.g.,

    reply_upper(INCHWL);
    PRINT(upper(name));

It is not  necessary to have a  RETURN statement in  untyped procedures.
If you  do have  a RETURN statement  in an  untyped procedure  it CANNOT
specify a value; and if you have a RETURN statement in a typed procedure
it MUST specify a value to be returned.  If there is no RETURN statement
in a typed procedure then the value returned will be garbage for integer
and real procedures  or the null string  for string procedures;  this is
not good coding practice.

Procedures  frequently will  RETURN(true) or  RETURN(false)  to indicate
success or a problem.  For example, a procedure which is supposed to get
a  filename  from  the  user  and open  the  file  will  return  true if
successful and false if no file was actually opened:

    IF getFile THEN processInput
               ELSE errorHandler(22) ;


This is quite  typical code where  you can see  that all the  tasks have
been  procedurized.   Many  programs will  have  25  pages  of procedure
declarations and then only 1 or 2 pages of actual statements calling the
appropriate procedures at the appropriate times.  In fact,  programs can
be written with pages of procedures and then only a single  statement to
call the main procedure.

Basically there are  two ways of giving  information to a  procedure and
three ways of returning information.  To give information you can 1) use
parameters to pass the information  explicitly or 2) make sure  that the
appropriate values are in global  variables at the time of the  call and
code  the procedures  so that  they access  those variables.   There are
several disadvantages to the latter approach although it  certainly does
have its uses.

First, once a piece of information has been assigned to a parameter, the
coding proceeds smoothly.   When you write  the procedure call,  you can
check the parameter  list and see at  a glance what arguments  you need.
If you instead use a global  variable then you need to remember  to make
sure it has the right value at the time of each procedure call.  In fact
in a complicated  program you will  have enough trouble  remembering the
name of the variable.  This  is one of the beauties of  procedures.  You
can think about  the task and  all the components  of the task  and code
them once and then  when you are in  the middle of another  larger task,
you only  need to give  the procedure  name and the  values for  all the
parameters (which  are clearly  specified in the  parameter list  so you
don't have to remember them) and  the subtask is taken care of.   If you
don't modularize your  programs in this way,  you are juggling  too many
open tasks at  the same time.  Another  approach is to tackle  the major
tasks first and  every time you  see a subtask  put in a  procedure call
with reasonable arguments and  then later actually write  the procedures
for the subtasks.  Usually a mixture of these approaches is appropriate;
and  you  will also  find  yourself carrying  particularly  good utility
procedures over from one program to another, building a library  of your
own general utility routines.

The second  advantage of  parameters over global  variables is  that the
global  variables  will  actually  be changed  by  any  code  within the
procedures but variables used as parameters to procedures will not.  The
changing of global  variables is sometimes  called a side-effect  of the
procedure.

Here are a pair of procedures that illustrate both these points:

    BOOLEAN PROCEDURE Ques1 (STRING s);
    BEGIN "Ques1"
    IF "?" = LOP(s) THEN RETURN(true)
                    ELSE RETURN(false);
    END "Ques1";

    STRING str;
    BOOLEAN PROCEDURE Ques2 ;
    BEGIN "Ques2"
    IF "?" = LOP(str) THEN RETURN(true)
                      ELSE RETURN(false);
    END "Ques2";

The second  procedure has these  problems: 1) we  have to make  sure our
string is in  the string variable str  before the procedure call  and 2)


str is  actually modified by  the LOP so  we have to  make sure  we have
another copy of it.  With the first procedure, the string to  be checked
can be anywhere and no copy is needed.  For example, if we want to check
a string called command, we give Ques1(command) and the LOP done  on the
string in Ques1 will not affect command.

Information can be returned from procedures in three ways:

       1)  With a RETURN(value) statement.

       2)  Through global variables.  You may sometimes actually want
   to change a global  variable.  Also, procedures can only  return a
   single value so if you have several values being generated  in the
   procedure, you may use global variables for the others.

       3)  Through  REFERENCE parameters.   Parameters can  be either
   VALUE or  REFERENCE.  By default  all scalar parameters  are VALUE
   and array  parameters are REFERENCE.   Array parameters  CANNOT be
   value; but scalars can be declared as reference parameters.  Value
   parameters as we have seen are simply used to pass a value  to the
   variable  which appears  in the  procedure.   Reference parameters
   actually  associate the  variable address  given in  the procedure
   call with the variable in  the procedure so that any  changes made
   will be made to the calling variable.

       PROCEDURE manyReturns
       (REFERENCE INTEGER i,j,k,l,m);
           BEGIN
             i_i+1; j_j+1; k_k+1; l_l+1; m_m+1;
           END;

   when called with

       manyReturns(var1,var2,var3,var4,var5);

   will  actually  change  the  var1,..,var5   variables  themselves.
   Arrays  are  always  called by  reference.   This  is  useful; for
   example, you might have a

       PROCEDURE sorter (STRING ARRAY arry) ;

   which sorts  a string array  alphabetically.  It will  actually do
   the sorting on the array that  you give it so that the  array will
   be sorted when the procedure returns.  Note that arrays  cannot be
   returned with the RETURN statement so this eliminates the need for
   making all your arrays global as a means of returning them.

See  the  Sail  manual  (Sec. 2)  for  details  on  using  procedures as
parameters to other procedures.


                               SECTION  3

                                 Macros




Sail macros are basically string substitutions made in your  source code
by the scanner during compilation.   Think of your source file  as being
read by  a scanner  that substitutes definitions  into the  token stream
going to  a logical  "inner compiler".   Anything that  one can  do with
macros,  one  could  have   done  without  them  by  editing   the  file
differently.  Macros are used for several purposes.

They are used to define named constants, e.g.,

        BEGIN
        REQUIRE "{}{}" DELIMITERS;
        DEFINE maxSize = {100} ;
        REAL ARRAY arry [1:maxSize];
                .
                .

The {}'s are used as delimiters placed around the right-hand-side of the
macro definition.  Wherever the token maxSize appears, the  scanner will
substitute 100 before the code is compiled.  These substitutions  of the
source text on  the right-hand-side of the  DEFINE for the token  on the
left-hand-side wherever  it subsequently appears  in the source  file is
called expanding  the macro.   The above  array declaration  after macro
expansion is:

        BEGIN
        REAL ARRAY arry [1:100];
                .
                .

which is more efficient than using:

        BEGIN INTEGER maxSize;
        maxSize_100;
            BEGIN
            REAL ARRAY arry [1:maxSize];
                .
                .
Also, in this example, the use of the integer variable for assignment of
the maxSize means that  the array bounds declaration is  variable rather
than constant so it must be  in an inner block; with the  macro, maxSize
is a constant so the array can be declared anywhere.

Other advantages to using macros to define names for constants are  1) a
name like  maxSize used  in your code  is easier  to understand  than an
arbitrary number when you or someone else is reading through the program
and 2) maxSize will undoubtedly  appear in many contexts in  the program
but if it needs to be changed, e.g., to 200, only the  single definition
needs changing.  If you had  used 100 instead of maxSize  throughout the
program then you would have to change each 100 to 200.

Before giving  your DEFINEs you  should require some  delimiters.  {}{},
[][], or  <><> are good  choices.  If you  don't require  any delimiters


then the defaults are """"  which are probably a poor choice  since they
make it hard to define  string constants.  The first pair  of delimiters
given  in  the REQUIRE  statement  are for  the  right-hand-side  of the
DEFINE.  See the Sail  manual for details on  use of the second  pair of
delimiters.

DEFINEs  may  appear  anywhere  in  your  program.   They   are  neither
statements  nor declarations.   REQUIREs can  be either  declarations or
statements so they can also go anywhere in your program.

Another use of macros is to define octal characters.  If you  have tried
to  use any  of the  sample  programs here  you will  have  discovered a
glaring  bug.  Each  time  we have  output  our results  with  the PRINT
statement, no account  has been taken of  the need for a  CRLF (carriage
return and  line feed) sequence.   So all the  lines will  run together.
Here are 4 possible solutions to the problem:

    1)  PRINT("Some text.", ('15&'12));

    2)  PRINT("Some text.
");

    3)  STRING crlf;
        crlf_"
";      PRINT ("Some text.",crlf);

    4)  REQUIRE "{}" DELIMITERS;
        DEFINE crlf = {"
"};     PRINT("Some text.",crlf);


The  first solution  is hard  to type  frequently with  the octals.  (In
general, concatenations should be avoided if possible since  new strings
must usually be created for  them; but in this case with  only constants
in the concatenation, it will be  done at compile time so that is  not a
consideration.) The  second solution  with the  string extending  to the
next line to get the crlf  is unwieldy to use in your code.   The fourth
solution is both the easiest to type and the most efficient.

You may also want to define a number of the other commonly  used control
characters:

        REQUIRE "<><>" DELIMITERS;
        DEFINE ff = <('14&NULL)>,
               lf = <('12&NULL)>,
               cr = <('15&NULL)>,
              tab = <('11&NULL)>,
             ctlO = <'17>;

The characters which  will be used as  arguments in the  PRINT statement
must be forced to be  strings.  If ff = <'14> were used;  then PRINT(ff)
would print the number 12 (which is '14) rather than to print a formfeed
because PRINT  would treat  the '14 as  an integer.   For all  the other
places that you  can use these  single character definitions,  they will
work correctly whether defined as strings or integers, e.g.,

        IF char = ctlO THEN ....

as well as



        IF char = ff THEN ....


Note that string constants  like '15&'12 and '14&NULL do  not ordinarily
need parenthesizing but ('15&'12) and ('14&NULL) were used  above.  This
is a little trick to compile more efficient code.  The compiler will not
ordinarily recognize these as  string constants when they appear  in the
middle of a concatenated string, e.g.,

        "....line1..."&'15&'12&"....line2..."

but with the proper parenthesizing

        "....line1..."&('15&'12)&"....line2..."

the compiler will  treat the crlf as  a string constant at  compile time
and not need to do a concatenation on '15 and '12 every time at runtime.

Another very common use of macros is to "personalize" the  Sail language
slightly.   Usually  macros  of  this  sort  are  used  either  to  save
repetitive typing of long sequences  or to make the code where  they are
used clearer.  (Be careful--this can be carried overboard.)

Here are some sample definitions followed by an example of their  use on
the next line:

    REQUIRE "<><>" DELIMITERS;

    DEFINE upto = <STEP 1 UNTIL>;
        FOR i upto 10 DO ....;

    DEFINE ! = <COMMENT>;
        i_i+1;          ! increment i here;

    DEFINE forever = <WHILE TRUE>;
        forever DO ....;

    DEFINE eif = <ELSE IF>;
        IF ... THEN ....
          EIF .... THEN ....
          EIF .... THEN ....;

Macros may also have parameters:

    DEFINE append(x,y) = <x_x&y>;
        IF LENGTH(s) THEN append(t,LOP(s));

    DEFINE inc(n) = <(n_n+1)>,
           dec(n) = <(n_n-1)>;
        IF inc(ptr) < maxSize THEN ....;
    COMMENT watch that you don't forget
            needed parentheses here;

    DEFINE ctrl(n) = <("n"-'100)>;
        IF char = ctrl(O) THEN abortPrint;

As we saw in some of the sample macros, the macro does not need to  be a
complete  statement,  expression,  etc.   It  can  be  just  a fragment.


Whether or not you want to use macros like this is a matter  of personal
taste.  However, it is quite clear that something like the  following is
simply terrible code although syntactically correct (and rumored to have
actually occurred in a program):

    DEFINE printer = <PRINT(>;
        printer "Hi there.");

which expands to

    PRINT("Hi there.");

On the other  hand, those who completely  shun macros are erring  in the
other direction.  One of the best coding practices in Sail is  to DEFINE
all constant parameters such as array bounds.


                               SECTION  4

                            String Scanning




We have not yet covered Input/Output which is one of the  most important
topics.  Before we do that, however, we will cover the SCAN function for
reading strings.  SCAN which  reads existing strings is very  similar to
INPUT which is used to read in text from a file.

Both SCAN and INPUT use  break tables.  When you are reading,  you could
of course  read the  entire file  in at once  but this  is not  what you
usually want even if the file  would all fit (and with the case  of SCAN
for strings it would be pointless).  A break table is used to 1)  set up
a list of characters which when read will terminate the scan, 2)  set up
characters which  are to be  omitted from the  resulting string,  and 3)
give  instructions  for  what  to  do  with  the  break  character  that
terminated the  scan (append  it to  the result  string, throw  it away,
leave it  at the  new beginning of  the old  string, etc.).   During the
course of a  program, you will want  to scan strings in  different ways,
for example:  scan and  break on a  non-digit to  check that  the string
contains only digits,  scan and break on  linefeed (lf) so that  you get
one line of text at a time, scan and omit all spaces so that you  have a
compact  string,  etc.  For  each  of these  purposes  (which  will have
different break  characters, omit characters,  disposition of  the break
character, and setting of certain other modes available), you  will need
a  different break  table.  You  are allowed  to set  up as  many  as 54
different break tables in a  program.  These are set up with  a SETBREAK
command.

A break  table is referred  to by  its number (1  to 54).   The GETBREAK
procedure is  used to  get the  number of  the next  free table  and the
number is stored in an  integer variable.  GETBREAK is a  relatively new
feature.  Previously, programmers had to keep track of the  free numbers
themselves.  GETBREAK  is highly recommended  especially if you  will be
interfacing your  program with another  program which is  also assigning
table  numbers  and may  use  the  same number  for  a  different table.
GETBREAK will know about all the table numbers in use.  You  assign this
number  to a  break table  by giving  it as  the first  argument  to the
SETBREAK function.  You can also use RELBREAK(table#) to release a table
number for reassignment when you no longer need that break table.

   SETBREAK(table#, "break-characters",
            "omit-characters", "modes") ;

where the  first argument is  an integer and  the ""'s around  the other
arguments here are a standard  way of indicating, in a  sample procedure
call, that the argument expected is a string.  For example:

  REQUIRE "<><>" DELIMITERS;
  DEFINE lf = <'12>, cr = <'15>,  ff = <'14>;
  INTEGER lineBr, nonDigitBr, noSpaces;

  SETBREAK(lineBr_GETBREAK, lf, ff&cr, "ins");
  SETBREAK(noSpaces_GETBREAK, NULL, " ", "ina");
  SETBREAK(nonDigitBr_GETBREAK, "0123456789",
           NULL, "xns");


The  characters in  the "break-characters"  string will  be used  as the
break characters to terminate the SCAN or INPUT.  SCAN and  INPUT return
that portion of the initial string up to the first occurrence of  one of
the break-characters.

The characters in the "omit-characters" string will be omitted  from the
string returned.

The "modes" establish what is  to be done with the break  character that
terminated the SCAN  or INPUT.  Any  combination of the  following modes
can be given by putting the mode letters together in a string constant:

                 CHARACTERS USED FOR BREAK CHARACTERS:

"I"  (inclusion)  The characters in the break-characters string  are the
   set of characters which will terminate the SCAN or INPUT.

"X"  (eXclusion)  Any  character  except those  in  the break-characters
   string will terminate the SCAN or INPUT, e.g., to break on  any digit
   use:

    INTEGER tbl;
    SETBREAK(tbl_GETBREAK,"0123456789",NULL,"i");

   and to break on any non-digit use:

    INTEGER tbl;
    SETBREAK(tbl_GETBREAK,"0123456789","","x");

   where NULL  or ""  can be used  to indicate  no characters  are being
   given for that argument.

                    DISPOSITION OF BREAK CHARACTER:

"S"  (skip)  The character which  actually terminates the SCAN  or INPUT
   will  be "skipped"  and thus  will not  appear in  the  result string
   returned nor will it be still in the original string.

"A"  (append)  The terminating character will be appended to the  end of
   the result string.

"R"  (retain)  The  terminating  character  will  be  retained   in  its
   position  in  the  original  string so  that  it  will  be  the first
   character read by the next SCAN or INPUT.

                       OTHER MISCELLANEOUS MODES:

"K"  This mode will convert characters to be put in the result string to
   uppercase.

"N"  This mode will discard SOS line numbers if any and  should probably
   be used  for break tables  which will be  scanning text from  a file.
   This is  a very  good Sail coding  practice even  if it  seems highly
   unlikely that an SOS file will ever be given to your program.

  "result-string" _ SCAN(@"source",table#, @brchar);

In these sample formats, the ""'s mean the argument is a string  and the
@ prefix means that the argument is an argument by reference.


When you call the SCAN function, you give it as arguments 1)  the source
string, 2) the break table number and 3) the name of an INTEGER variable
where it  will put  a copy of  the character  that terminated  the scan.
Both the  source string  and the break  character integer  are reference
parameters  to the  SCAN procedure  and will  have new  values  when the
procedure is finished.  The following example illustrates the use of the
SCAN procedure and also shows how the "S", "A", and "R" modes affect the
resulting strings with the disposition of the break character.


    INTEGER skipBr, appendBr, retainBr, brchar;
    STRING result, skipStr, appendStr, retainStr;

    SETBREAK(skipBr_GETBREAK,"*",NULL,"s");
    SETBREAK(appendBr_GETBREAK,"*",NULL,"a");
    SETBREAK(retainBr_GETBREAK,"*",NULL,"r");

    skipStr_appendStr_retainStr_"first*second";
    result _ SCAN(skipStr, skipBr, brchar);
    COMMENT EQU(result,"first") AND
            EQU(skipStr,"second");

    result _ SCAN(appendStr, appendBr, brchar);
    COMMENT EQU(result,"first*") AND
            EQU(appendStr,"second");

    result _ SCAN(retainStr, retainBr, brchar);
    COMMENT EQU(result,"first") AND
            EQU(retainStr,"*second");

    COMMENT in each case above  brchar = "*"
            after the SCAN;

Now we can look again at the break tables given above:

        SETBREAK(lineBr,lf,ff&cr,"ins");

This break table will return a  single line up to the lf.   Any carriage
returns or formfeeds  (usually used as page  marks) will be  omitted and
the break character is also  omitted (skipped) so that just the  text of
the line will be returned  in the result string.  The  more conventional
way to read line by line where the line terminators are preserved is

        SETBREAK(readLine,lf,NULL,"ina");

Note here that it is extremely important that lf rather than cr  be used
as  the break  character since  it follows  the cr  in the  actual text.
Otherwise, you'll end up with strings like

        text of line<cr>
        <lf>text of line<cr>
        <lf>

instead of

        text of line<cr><lf>
        text of line<cr><lf>

After the SCAN,  the brchar variable can  be either the  break character


that terminated the scan  (lf in this case)  or 0 if no  break character
was  encountered and  the scan  terminated by  reaching the  end  of the
source string.

    DO       processLine(SCAN(str,readLine,brchar))
       UNTIL NOT brchar;

This code would be used if  you had a long multi-lined text stored  in a
string  and wanted  to process  it  one line  at a  time  with PROCEDURE
processLine.

        SETBREAK(nonDigitBr,"0123456789",NULL,"xs");

This break table could be used to check if a number input from  the user
contains only digits.

    WHILE true DO
        BEGIN
        PRINT("Type a number: ");
        reply_INCHWL;       ! INTTY for TENEX;
        SCAN(reply,nonDigitBr,brchar);
        IF brchar THEN
          PRINT(brchar&NULL," is not a digit.",crlf)
          ELSE DONE;
        END;

Here  the value  of brchar  (converted to  a string  constant  since the
integer character  code will  probably be meaningless  to the  user) was
printed out to  show the user the  offending character.  There  are many
other uses of the brchar variable particularly if a number of characters
are  specified in  the break-characters  string of  the break  table and
different actions are  to be taken depending  on which one  actually was
encountered.

        SETBREAK(noSpaces,NULL," ","ina");

Here there  are no  break-characters but  the omit-character(s)  will be
taken care of by the scan, e.g.,

        str_"a b c d";
        result_SCAN(str,noSpaces,brchar);

will return "abcd" as the result string.

If you need to  scan a number which is  stored in a string,  two special
scanning functions, INTSCAN and REALSCAN, have been set up which  do not
require break tables but have the appropriate code built in:

    integerVar _ INTSCAN("number-string",@brchar);
    realVar _ REALSCAN("number-string",@brchar);

where  the integer  or  real number  read  is returned;  and  the string
argument after the  call contains the remainder  of the string  with the
number removed.  We could use INTSCAN to check if a string input  from a
user is really a proper number.

        PRINT("Type the number: ");
        reply _ INCHWL;   ! INTTY for TENEX;
        numb _ INTSCAN(reply,brchar);
        IF brchar THEN error;


                               SECTION  5

                             Input/Output 




5.1  Simple Terminal I/O

We have been doing input/output (I/O) from the controlling terminal with
INCHWL (or INTTY for TENEX)  and PRINT.  A number of other  Teletype I/O
routines are listed in the Sail manual in Sections 7.5 and 12.4 but they
are less often used.   Also any of the  file I/O routines which  will be
covered next can  be used with  the TTY: specified  in place of  a file.
Before  we  cover file  I/O,  a few  comments  are needed  on  the usual
terminal input and output.

The INCHWL (INTTY) that we have used is like an INPUT with the source of
input prespecified as the terminal and the break characters given as the
line terminators.  Should you ever  want to look at the  break character
which terminated an  INCHWL or INTTY, it  will be in a  special variable
called  !SKIP!  which  the  Sail runtimes  use  for  a  wide  variety of
purposes.  INTTY will input a  maximum of 200 characters.  If  the INTTY
was terminated for reaching the maximum limit then !SKIP! will be set to
-1.  Since this variable is declared in the runtime package  rather than
in your program, if you are going to be looking at it, you will  need to
declare it also, but as an EXTERNAL, to tell the compiler that  you want
the runtime variable.

    EXTERNAL INTEGER !SKIP!;
    PRINT("Number followed by <CR> or <ALT>: ");
    reply_INCHWL;     ! INTTY for TENEX;
    IF !SKIP! = cr THEN ......
        ELSE IF !SKIP! = alt THEN .....

Altmode  (escape,  enter,  etc.)  is  one  of  the  characters  which is
different in the different character sets.  The standard for most of the
world including both  TOPS-10 and TENEX is  to have altmode as  '33.  At
some  point  in the  past  TOPS-10  used '176.   This  is  now obsolete;
however, the  SU-AI character  set follows this  convention but  does so
incorrectly.  It uses '175 as altmode.  This will present a  problem for
programs transported among sites.   It also partially explains  why most
systems when they believe they  are dealing with a MODEL-33  Teletype or
other uppercase  only terminal  (or are  in @RAISE  mode in  TENEX) will
convert the characters '173 to '176 to altmodes.



5.2  Notes on Terminal I/O for TENEX Sail Only

If you are programming in TENEX Sail, you should use INTTY in preference
to the various teletype routines  listed in the manual.  TENEX  does not
have a line editor built in.  You can get the effect of a line editor by
using INTTY which allows the user to edit his/her typing with  the usual
^A, ^R, ^X, etc. up until the point where the line terminator  is typed.
If you  use INCHWL, the  editing characters are  only DEL to  rubout one
character and ^U to start over.  Efforts have been made in TENEX Sail to
provide  line-editing  where needed  in  the various  I/O  routines when
accessing the controlling  terminal.  Complete details are  contained in
Section 12 of the Sail manual.


TENEX  also  has a  non-standard  use  of the  character  set  which can
occasionally cause  problems.  The original  design of TENEX  called for
replacing crlf sequences with  the '37 character (eol).  This  has since
been largely abandoned and most TENEX programs will not output text with
eol's but  rather use the  standard crlf.  Eol's  are still used  by the
TENEX system itself.  The Sail input routines INPUT, INTTY, etc. convert
eol's to crlf sequences.  See the Sail manual for details, if necessary;
but in general, the only time that you should ever have a problem  is if
you  input from  the terminal  with some  routine that  inputs  a single
character at  a time,  e.g., CHARIN.  In  these cases  you will  need to
remember that end-of-line will be signalled by an eol rather than  a cr.
The user of course  types a cr but TENEX  converts to eol; and  the Sail
single character  input functions do  not reconvert to  cr as  the other
Sail input functions do.



5.3  Setting Up a Channel for I/O

Now we need I/O for files.  The input and output operations to files are
much  like  what we  have  done  for the  terminal.   CPRINT  will write
arguments to a file  as PRINT writes them  to the terminal.  It  is also
possible with the SETPRINT command to specify that you would rather send
your PRINT's to a file (or  to the terminal AND a named file).   See the
manual for details.

There are a number of  other functions available for I/O in  addition to
INPUT and CPRINT, but they all have one common feature that we  have not
seen before.  Each requires as first argument a channel number.  The CPU
performs  I/O through  input/output channels.   Any device  (TTY:, LPT:,
DTA:, DSK:, etc.) can be at the other end of the channel.  Note  that by
opening the controlling terminal (TTY:) on a channel, you can use any of
the input/output routines available.   In the case of  directory devices
such as DSK: and DTA:, a  filename is also necessary to set up  the I/O.
There   are  several   steps  in   the  process   of   establishing  the
source/destination of I/O on a numbered channel and getting it ready for
the actual transfer.  This is  the area in which TOPS-10 and  TENEX Sail
have the most  differences due to the  differences in the  two operating
systems.  Therefore separate sections will be included here  for TOPS-10
and TENEX Sail and you should read only the one relevant for you.

5.3.1  TOPS-10 Sail Channel and File Handling

Routines  for  opening  and closing  files  in  TOPS-10  Sail correspond
closely to the UUO's available in the TOPS-10 system.  The main routines
are:

        GETCHAN OPEN LOOKUP ENTER RELEASE

Additional routines (not discussed here) are:

        USETI USETO MTAPE CLOSE CLOSIN CLOSO


5.3.1.1  Device Opening

        chan _ GETCHAN;

GETCHAN obtains  the number  of a  free channel.   On a  TOPS-10 system,
channel  numbers are  0  through '17.   GETCHAN  finds the  number  of a
channel not currently in use by Sail and returns that number.   The user
is advised to use GETCHAN  to obtain a channel number rather  than using
absolute channel numbers.

        OPEN(chan, "device", mode, inbufs,
             outbufs, @count, @brchar, @eof);

The OPEN procedure corresponds to the TOPS-10 OPEN (or INIT)  UUO.  OPEN
has eight parameters.  Some of  these refer to parameters that  the OPEN
UUO will need; other  parameters specify the number of  buffers desired,
with other UUO's  called by OPEN to  set up this buffering;  still other
parameters are internal Sail bookkeeping parameters.

The parameters to OPEN are:

       1)  CHANNEL: channel number, typically the number  returned by
   GETCHAN.

       2)  "DEVICE": a string argument that is the name of the device
   that  is desired,  such as  "DSK" for  the disk  or "TTY"  for the
   controlling terminal.

       3)  MODE:  a  number  indicating the  mode  of  data transfer.
   Reasonable values are:  0 for characters  and strings and  '14 for
   words and arrays  of words.  Mode '17  for dump mode  transfers of
   arrays is sometimes used but is not discussed here.

       4)  INBUFS: the number of input buffers that are to be set up.

       5)  OUTBUFS: the number of output buffers.

       6)  COUNT: a reference parameter specifying the maximum number
   of characters for the INPUT function.

       7)  BRCHAR: a  reference parameter in  which the  character on
   which INPUT broke will be saved.

       8)  EOF: a reference parameter  which is set to TRUE  when the
   file is at the end.

The CHANNEL, "DEVICE", and MODE  parameters are passed to the  OPEN UUO;
INBUFS and OUTBUFS tell the Sail runtime system how many  buffers should
be set up  for data transfers; and  the COUNT, BRCHAR and  EOF variables
are cells that  are used by Sail  bookkeeping.  N.B.: many of  the above
parameters have additional  meanings as given  in the Sail  manual.  The
examples in this  section are intended to  demonstrate how to  do simple
things.


        RELEASE(chan);

The RELEASE  function, which  takes the channel  number as  an argument,
finishes all the  input and output and  makes the channel  available for
other use.

The following routine  illustrates how to open  a device (in  this case,
the device is only the teletype) and output to that device.   The CPRINT
function,  which  is  like  PRINT except  that  its  output  goes  to an
arbitrary channel destination, is used.

    BEGIN
    INTEGER OUTCHAN;

    OPEN(OUTCHAN _ GETCHAN,"TTY",0,0,2,0,0,0);
    COMMENT
            (1)  Obtain a channel number, using
    GETCHAN, and save it in variable OUTCHAN.
            (2)  Specify device TTY, in mode 0,
    with 0 input and 2 output buffers.
            (3)  Ignore the COUNT, BRCHAR, and EOF
    variables, which are typically not needed if
    the file is only for output. ;

    CPRINT(OUTCHAN, "Message for OUTCHAN
    ");
    COMMENT Actual data transfer.;

    RELEASE(OUTCHAN);
    COMMENT Close channel;
    END;

The following example illustrates how to read text from a  device, again
using the teletype as the device.

    BEGIN
    INTEGER INCHAN, INBRCHAR, INEOF;

    OPEN (INCHAN _ GETCHAN, "TTY", 0, 2, 0, 200,
          INBRCHAR, INEOF);
    COMMENT
       Opens the TTY in mode  0 (characters), with
       2 input buffers, 0 output buffers.  At most
       200 characters will  be read  in with  each
       INPUT  statement, and  the break  character
       will  be put  into variable  INBRCHAR.  The
       end-of-file  will  be  signalled  by  INEOF
       being  set to  TRUE after  some call  to an
       input function has found  that there is  no
       more data in the file;

    WHILE NOT INEOF DO
        BEGIN
            ... code to do input -- see below. ...
        END;
    RELEASE(INCHAN);

    END;


5.3.2  Reading and Writing Disk Files

Most input and output will probably be done to the disk.  The disk (and,
typically,  the  DECtape)  are  directory  devices,  which   means  that
logically separate files are  associated with the device.  When  using a
directory device,  it is  necessary to  associate a  file name  with the
channel that is open to the device.

        LOOKUP(CHAN, "FILENAME", @FLAG);
        ENTER(CHAN, "FILENAME", @FLAG);

File names  are associated  with channels  by three  functions:  LOOKUP,
ENTER, and RENAME.  We will discuss LOOKUP and ENTER here.   Both LOOKUP
and ENTER take  three arguments: a channel  number, such as  returned by
GETCHAN, which has already been opened; a text string which is  the name
of the file,  using the file name  conventions of the  operating system;
and a  reference flag  that will  be set  to FALSE  if the  operation is
successful,  or  TRUE  otherwise.   (The TRUE  value  is  a  bit pattern
indicating the exact cause of failure, but we will not be concerned with
that here.)  There are three  permutations of LOOKUP and ENTER  that are
useful:

       1)  LOOKUP  alone:  this is  done  when you  want  to  read an
   already existing file.

       2)  ENTER alone: this is done  when you want to write  a file.
   If a file already exists with the selected name, then a new one is
   created, and upon closing of the file, the old version  is deleted
   altogether.  This is the standard way to write a file.

       3)  A LOOKUP followed by an ENTER using the same name: this is
   the standard way to read and write an already existing file.

The following program  will read an  already existing text  file, (e.g.,
with the INPUT,  REALIN, and INTIN  functions, which scan  ASCII text.) 
Note that  the LOOKUP  function is  used to  see if  the file  is there,
obtaining the  name of the  file from the  user.  See below  for details
about the functions that are used for the actual reading of the  data in
the file.



    BEGIN
    INTEGER INCHAN, INBRCHAR, INEOF, FLAG;
    STRING FILENAME;

    OPEN (INCHAN _ GETCHAN, "DSK", 0, 2, 0, 200,
          INBRCHAR, INEOF);

    WHILE TRUE DO
        BEGIN
          PRINT("Input file name  *");
          LOOKUP(INCHAN, FILENAME _ INCHWL, FLAG);
          IF FLAG THEN DONE ELSE
            PRINT("Cannot find file ", FILENAME,
    " try again.
    ");
        END;

    WHILE NOT INEOF DO
        BEGIN "INPUT"
            .... see below for reading characters...
        END "INPUT";

    RELEASE(INCHAN);
    END;

The following program opens a file for writing characters.

    BEGIN
    INTEGER OUTCHAN, FLAG;
    STRING FILENAME;

    OPEN (OUTCHAN _ GETCHAN, "DSK", 0, 0, 2, 0,
          0, 0);

    WHILE TRUE DO
        BEGIN
          PRINT("Output file name  *");
          ENTER(OUTCHAN, FILENAME _ INCHWL, FLAG);
          IF NOT FLAG THEN DONE ELSE
            PRINT("Cannot write file ", FILENAME,
    "  try again.
    ");
        END;

     ... now write the text to OUTCHAN ...

    RELEASE(OUTCHAN);
    END;


5.3.2.1  Reading and Writing Full Words

Reading 36-bit PDP10 words,  using WORDIN and ARRYIN, and  writing words
using WORDOUT and ARRYOUT, is  accomplished by opening the file  using a
binary mode such as '14.  We recommend the use of binary mode, with 2 or
more  input and/or  output  buffers selected  in  the call  to  the OPEN
function.  There are  other modes available, such  as mode '17  for dump
mode transfers; see the timesharing manual for the operating system.



5.3.2.2  Other Input/Output Facilities

Files can be renamed using  the RENAME function.  Some random  input and
output is offered by the USETI and USETO functions, but random input and
output  produces  strange results  in  TOPS-10 Sail.   Best  results are
obtained by using USETI and USETO and reading or writing 128-word arrays
to the disk with ARRYIN and ARRYOUT.

Magnetic tape operations are performed with the MTAPE function.

See the Sail manual (Sec. 7) for more details about these functions.  In
particular, we stress that we  have not covered all the  capabilities of
the functions that we have discussed.



5.3.3  TENEX Sail Channel and File Handling

TENEX Sail has included all  of the TOPS-10 Sail functions  described in
Section 7.2  of the  Sail manual  for reasons  of compatibility  and has
implemented them suitably to  work on TENEX.  Descriptions of  how these
functions  actually work  in  TENEX are  given  in Section  12.2  of the
manual.   However,  they  are  less  efficient  than  the  new   set  of
specifically TENEX routines which have  been added to TENEX Sail  so you
probably  should  skip these  sections  of the  manual.   The  new TENEX
routines are also  greatly simplified for the  user so that a  number of
the steps to establishing the I/O are done transparently.

Basically,  you only  need  to know  three commands:  1)  OPENFILE which
establishes a file on  a channel, 2) SETINPUT which  establishes certain
parameters for the subsequent inputs  from the file, and 3)  CFILE which
closes the file and releases the channel when you are finished.

        chan# _ OPENFILE("filename","modes")

The OPENFILE function takes 2 arguments: a string containing  the device
and/or filename and a string  constant containing a list of  the desired
modes.  OPENFILE returns  an integer which is  the channel number  to be
used  in all  subsequent inputs  or outputs.   If you  give NULL  as the
filename then OPENFILE goes to the user's terminal to get the name.  (Be
sure if you do this that you first PRINT a prompt to the terminal.)  The
modes are listed  in the Sail  manual (Sec. 12.3)  but not all  of those
listed are  commonly used.   The following  are the  ones that  you will
usually give:

   R or W or A  for  Read, Write,  or  Append depending  on  what you
       intend to do with the file.


   *            if you are allowing multi-file  specifications, e.g.,
       data.*;* .

   C            if the user is giving the filename from the terminal,
       C mode will prompt for [confirm].

   E              if the  user is  giving the  filename and  an error
       occurs (typically  when the  wrong filename  is typed),  the E
       mode returns control to  your program.  If E is  not specified
       the user is automatically asked to try again.

Modes  O  and N  for  Old or  New  File are  also  allowed  but probably
shouldn't be  used.  They are  misleading.  The defaults,  e.g.  without
either O or N specified,  are the usual conditions (read an  old version
and  write a  new version).   The  O and  N options  are  peculiar.  For
example, "NW" means that you must specify a completely new  filename for
the file to be written, e.g.,  a name that has not been used  before.  N
does not mean a new version as one might have expected.  In general, the
I/O routines use  the relevant JSYS's directly  and thus include  all of
the design errors and bugs in the JSYS's themselves.

        INTEGER infile, outfile, defaultsFile;
        PRINT("Input file: ");
        inFile _ OPENFILE(NULL,"rc");
        PRINT("Output file: ");
        outFile _ OPENFILE(NULL,"wc");
        defaultsFile _
              OPENFILE("user-defaults.tmp","w");

We now  have files  "open" on 3  channels--one for  reading and  two for
writing.  We  have the  channel numbers stored  in inFile,  outFile, and
defaultsFile so that  we can refer to  the appropriate channel  for each
input or output.  Next we need to do a SETINPUT on the channel  open for
input (reading).

        SETINPUT(chan#, count, @brchar, @eof)

There are four arguments:

       1)  The channel number.

       2)  An  integer  number   which  is  the  maximum   number  of
   characters to be  read in any input  operation (the default  if no
   SETINPUT is done is 200).

       3)  A reference integer variable where the input function will
   put the break character.

       4)  A reference integer variable where the input function will
   put true or false for  whether or not the end-of-file  was reached
   (or the error number if an error was encountered while reading).

So here we need:

    INTEGER infileBrChr, infileEof;
    SETINPUT (infile, 200, infilebrchr, infileEof);

Now we do the relevant input/output operations and when finished:

        CFILE(infile);


        CFILE(outfile);
        CFILE(defaultsFile);

A simple example  of the use  of these routines  for opening a  file and
outputting to it is:

        INTEGER outfile;
        PRINT("Type filename for output:  ");
        outfile_OPENFILE(NULL,"wc");
        CPRINT(outfile, "message...");
        CFILE(outfile);

where  CPRINT is  like PRINT  except for  the additional  first argument
which is the channel number.

The OPENFILE, SETINPUT, and CFILE commands will handle  most situations.
If you have unusual requirements or like to get really fancy  then there
are  many variations  of file  handling available.   A few  of  the more
commonly used will be covered in the next section; but do not  read this
section until you  have tried the regular  routines and need to  do more
(if ever).  On first reading, you should now skip to Section 5.4.



5.3.4  Advanced TENEX Sail Channel and File Handling

If you want to use  multiple file designators with *'s, you  should give
"*"  as one  of the  options to  OPENFILE.  Then  you will  need  to use
INDEXFILE to sequence through the multiple files.  The syntax is

        found!another!file _ INDEXFILE(chan#)

where found!another!file is a boolean variable.   INDEXFILE accomplishes
two things.   First, if  there is another  file in  the sequence,  it is
properly initialized on the channel; and second, INDEXFILE  returns TRUE
to indicate  that it has  gotten another file.   Note that  the original
OPENFILE gets the first file in the sequence on the channel so  that you
don't use  the INDEXFILE  until you have  finished processing  the first
file and  are ready for  the second.  This  is done conveniently  with a
DO...UNTIL where the test is not made until after the first time through
the loop, e.g.,

    multiFiles _ OPENFILE("data.*","r*");
    DO
        BEGIN
        ...<input and process current file>...
        END
        UNTIL NOT INDEXFILE(multiFiles);

Another  available  option  to the  OPENFILE  routine  which  you should
consider using  is the "E"  option for error  handling.  If  you specify
this option and the user gives an incorrect filename then  OPENFILE will
return -1 rather than a  channel number and the TENEX error  number will
be returned in !SKIP!.   Remember to declare EXTERNAL INTEGER  !SKIP! if
you are  going to  be looking at  it.  Handling  the errors  yourself is
often  a good  idea.  TENEX  is  unmerciful.  If  the user  gives  a bad
filename, it will ask again and  keep on asking forever even when  it is
obvious after a certain number of tries that there is a  genuine problem
that needs to be resolved.


Another use for the "E" mode is to offer the user the option of typing a
bare <CR> to get a default file.  If the "E" mode has been specified and
the user types a carriage-return for the filename then we know  that the
error number returned in !SKIP!  will be the number (listed in  the JSYS
manual) for "Null filename not allowed." so we can intercept  this error
and simply do another OPENFILE with the default filename, e.g.,

    EXTERNAL INTEGER !SKIP!;
    outfile_-1;
    WHILE outfile = -1 DO
        BEGIN
        PRINT("Filename (<CR> for TTY:)  *");
        outfile_OPENFILE(NULL,"we");
        IF !skip! = '600115 THEN
            outfile_OPENFILE("TTY:","w");
        END;

The GTJFNL and GTJFN routines  are useful if you need more  options than
are  provided in  the OPENFILE  routine, but  neither of  these actually
opens the file so you will need an OPENF or OPENFILE after the GTJFNL or
GTJFN unless your purpose in using the GTJFN is specifically that you do
not want to open the file.  The GTJFNL routine is actually the long form
of the GTJFN JSYS; and the GTJFN routine is the short form of  the GTJFN
JSYS.  See the TENEX JSYS manual for details.

Another use of GTJFNL is to combine filename specification from a string
with filename  specification from  the user.   This is  a simple  way to
preprocess the filename from the user, i.e., to check if it is  really a
"?" rather than a filename.   First, you need to declare !SKIP!  and ask
the user for a filename:

    EXTERNAL INTEGER !SKIP!;
    WHILE TRUE DO
        BEGIN "getfilename"
        PRINT("Type input filename or ? : ");

Next do a regular INTTY to get the reply into a string:

        s _ INTTY;

Then you process the string in  any way that you choose, e.g.,  check if
it is a "?" or some other special keyword:

        IF s = "?" THEN  BEGIN
                         givehelp;
                         CONTINUE "getfilename";
                         END;

If you decide it is a proper  filename and want to use it then  you give
that string (with the break character from INTTY which will be in !SKIP!
appended back on to the end of the string) to the GTJFNL.

        chan# _ GTJFNL(s&!SKIP!, '160000000000,
                '000100000101, NULL, NULL, NULL,
                NULL, NULL, NULL);

If the  string ended in  altmode meaning that  the user  wanted filename
recognition then that will be done; and if the string is not  enough for
recognition and more typein is needed then the GTJFNL will ring the bell


and go  back to the  user's terminal without  the user knowing  that any
processing  has gone  on in  the meantime,  i.e., to  the user  it looks
exactly like the ordinary OPENFILE.   Thus the GTJFNL goes first  to the
string that  you give  it but  can then go  to the  terminal if  more is
needed.

After the  GTJFNL don't forget  that you still  need to OPENF  the file.
For reading a disk file,

        OPENF (chan#, '440000200000);

is a reasonable default, and for writing:

        OPENF (chan#, '440000100000);

The arguments to GTJFNL are:

    chan# _ GTJFNL("filename", flags, jfnjfn,
                    "dev", "dir", "name", "ext",
                    "protection", "acct");

where the  flag specification is  made by looking  up the FLAGS  for the
GTJFN  JSYS in  the JSYS  manual and  figuring out  which bits  you want
turned on and which off.  The 36-bit resulting word can be given here in
its octal representation.  '160000000000 means bits 2 (old file only), 3
(give messages) and  4 (require confirm)  are turned on.   Remember that
the bits start with Bit 0 on the left.  The jfnjfn will  probably always
be '000100000101.  This argument is for the input and output  devices to
be used if  the string needs to  be supplemented.  Here  the controlling
terminal is used for both.   Devices on the system have an  octal number
associated with them.  The controlling terminal as input device  is '100
and as output is '101.  For most purposes you can refer to  the terminal
by its "name" which is TTY: but here the number is required.   The input
and output devices are given  in half word format which means  that '100
is  in  the left  and  '101  in the  right  half of  the  word  with the
appropriate 0's filled out for the rest.

The next six arguments  to GTJFNL are for  defaults if you want  to give
them for: device, directory, file name, file extension, file protection,
and file account.  If no default is given for a field then  the standard
default (if any) is used, e.g., DSK: for device and  Connected Directory
for directory.  This  is another reason why  you may choose  GTJFNL over
OPENFILE for getting a filename.   In this way, you can set  up defaults
for the filename  or extension.  You can  also use GTJFNL to  simulate a
directory search path.  For example, the EXEC when accepting the name of
a program to be run follows a search path to locate the file.   First it
looks on <SUBSYS> for a file  of that name with a .SAV  extension.  Next
it looks on the connected directory and finally on the  login directory.
If you have an analogous situation, you can use a hierarchical series of
GTJFNL's with the appropriate defaults specified:

    EXTERNAL INTEGER !SKIP!;
    INTEGER logdir,condir,ttyno;
    STRING logdirstr,condirstr;

    GJINF(logdir,condir,ttyno);
    COMMENT puts the directory numbers for login
        and connected directory and the tty# in
        its reference integer arguments;
    logdirstr_DIRST(logdir);


    condirstr_DIRST(condir);
    COMMENT returns a string for the name
        corresponding to directory# ;
    WHILE true DO
      BEGIN "getname"
        PRINT("Type the name of the program: ");
        IF EQU (upper(NAME _ INTTY),"EXEC") THEN
          BEGIN
            name_"<SYSTEM>EXEC.SAV";
            DONE "getname";
          END;
        IF name = "?" THEN
          BEGIN
            givehelp;
            CONTINUE "getname";
          END;
        name_name&!SKIP!;
        COMMENT put the break char back on;
        DEFINE flag = <'100000000000>,
        jfnjfn = <'100000101>;
        IF (tempChan_GTJFNL(name,flag,jfnjfn,NULL,
            "SUBSYS",NULL,"SAV",NULL,NULL)) = -1
         THEN
          IF (tempChan_GTJFNL(name,flag,
             jfnjfn,NULL,condirstr,NULL,
             "SAV",NULL,NULL)) = -1 THEN
            IF (tempChan_GTJFNL(name,flag,
               jfnjfn,NULL,logdirstr,NULL,
               "SAV",NULL,NULL)) = -1 THEN
              BEGIN
                PRINT("  ?",crlf);
                CONTINUE "getname";
              END;
       COMMENT try each  default and if  not found
       then  try next  until  none are  found then
       print ?  and try again;
        name _ JFNS(tempChan, 0);
        COMMENT gets name of file on chan--0
                means in normal format;
        CFILE(tempChan);
        COMMENT channel not opened but does
            need to be released;
        DONE "getname";
        END;

In this case, we did not want to open a channel at all since we will not
be either reading  or writing the  .SAV file.  At  the end of  the above
code, the complete filename is stored in STRING name.  We might  wish to
run the  program with the  RUNPRG routine.  GTJFN  and GTJFNL  are often
used for the purpose of establishing filenames even though they  are not
to be opened at the moment.   However, the Sail channel does need  to be
released afterwards.

Some of  the other  JSYS's which  have been  implemented in  the runtime
package were  used in  this program:  GJINF, DIRST,  and JFNS.   JFNS in
particular is very useful.  It returns a string which is the name of the
file open  on the channel.   You might  need this name  to record  or to
print on the terminal or because you will be outputting to a new version
of the input file which you can't do unless you know its name.


These and a number  of other routines are  covered in Section 12  of the
Sail manual.  You should probably glance through and see what  is there.
Many of these commands  correspond directly to utility  JSYS's available
in TENEX and will be difficult  to use if you are not familiar  with the
JSYS's and the JSYS manual.



5.4  Input from a File

In this section, we will assume that you have a file opened  for reading
on  some  channel  and  are   ready  to  input.   Also  that   you  have
appropriately established the end-of-file and break  character variables
to be used by the input routines and the break table if needed.

Another function which can be used in conjunction with the various input
functions is SETPL:

        SETPL (chan#, @line#, @page#, @sos#)

This allows you to set  up the three reference integer  variables line#,
page#, and  sos# to  be associated with  the channel  so that  any input
function on the channel will update their values.  The line# variable is
incremented each  time a  '12 (lf) is  input and  the page#  variable is
incremented (and line# reset to 0) each time a '14 (formfeed)  is input.
The last SOS line  number input (if any)  will be in the  sos# variable.
The SETPL should be given before the inputting begins.

The major input function for text is INPUT.

        "result" _ INPUT(chan#, table#);

where  you give  as arguments  the channel  number and  the  break table
number;  and  the resulting  input  string is  returned.   This  is very
similar to SCAN.

To input one  line at a  time from a file  (where infile is  the channel
number and infileEof is the end-of-file variable):

    SETBREAK(readLine_GETBREAK,lf,NULL,"ina");
      DO
        BEGIN
        STRING line;
        line_INPUT(infile,readLine);
        ...<process the line>...
        END
      UNTIL infileEof;

If the INPUT function sets the eof variable to TRUE then either the end-
of-file was encountered or there was a read error of some sort.

If the  INPUT terminated  because a  break character  was read  then the
break character will  be in the brchar  variable.  If brchar=0  then you
have to look  at the eof variable  also to determine  what happened:  If
eof=TRUE then that  was what terminated the  INPUT but if  eof=FALSE and
brchar=0 then the INPUT was terminated by reaching the maximum count per
input that was specified for the channel.

If you are inputting numbers from the channel then


           realVar _ REALIN(chan#)
        integerVar _ INTIN(chan#)

which are like REALSCAN and INTSCAN can be used.  The brchar established
for  the channel  will be  used rather  than needing  to give  it  as an
argument as in the REALSCAN and INTSCAN.

INPUT is designed for files of text.  Several other input  functions are
available for other sorts of files.

        Number _ WORDIN(chan#)

will read in a 36-bit word  from a binary format file.  For  details see
the manual.

        ARRYIN(chan#, @loc, count)

is used for filling arrays with data from binary format files.  Count is
the number of 36-bit words to be read in from the file.  They are placed
in consecutive  locations starting with  the location specified  by loc,
e.g.,

        INTEGER ARRAY numbs [1:max];
        ARRYIN(dataFile,numbs[1],max);

ARRYIN can only be used for INTEGER and REAL arrays (not STRING arrays).

5.4.1  Additional TENEX Sail Input Routines

Two extra input routines which  are quite fast have been added  to TENEX
Sail to utilize the available input JSYS's.

        char _ CHARIN (chan#)

inputs a single character which can be assigned to an  integer variable.
If the file is at the end then CHARIN returns 0.

    "result" _
         SINI (chan#, maxlength, break-character)

does a very fast input of a string which is terminated by either reading
maxlength characters or encountering the break-character.  Note that the
break-character  here  is  not  a  reference  integer  where  the  break
character is to be returned;  rather it actually is the  break character
to  be used  like the  "break-characters" established  in a  break table
except that only one character can be specified.  If the SINI terminated
for reaching  maxlength then  !SKIP! = -1 else  !SKIP! will  contain the
break character.

TENEX Sail  also offers  random I/O  which is  not available  in TOPS-10
Sail.  A file bytepointer is maintained for each file and is initialized
to point at the beginning of the file which is byte 0.   It subsequently
moves through the file always  pointing to the character where  the next
read or write will begin.  In fact the same file may be read and written
at the same time (assuming  it has been opened in the  appropriate way).
If the  pointer could  only move in  this way  then only  sequential I/O
would be available.   However, you can reset  the pointer to  any random
position in  the file and  begin the read/write  at that point  which is
called random I/O.


        charptr _ RCHPTR (chan#)

returns the current position of the character pointer.  This is given as
an integer representing the number of characters (bytes) from  the start
of the file which is byte 0.  You can reset the pointer by

        SCHPTR (chan#, newptr)

If newptr is  given as -1  then the pointer will  be set to  the end-of-
file.

There are many uses for random I/O.  For example, you can store the help
text for a program in a separate file and keep track of  the bytepointer
to the start  of each individual message.   Then when you want  to print
out one of the  messages, you can set the  file pointer to the  start of
the appropriate message and print it out.

RWDPTR AND SWDPTR are also  available for random I/O with  words (36-bit
bytes) as the primary unit rather than characters (7-bit bytes).



5.5  Output to a File

The CPRINT function is used for outputting to text files.

        CPRINT (chan#, arg1, arg2, ...., argN)

CPRINT is just like PRINT except  that the channel must be given  as the
first argument.

    FOR i_1 STEP 1 UNTIL maxWorkers DO
        CPRINT(outfile, name[i], " ",
               salary[i],crlf);

Each  subsequent argument  is  converted to  a string  if  necessary and
printed out to the channel.

        WORDOUT(chan#, number)

writes a single 36-bit word to the channel.

        ARRYOUT(chan#, @loc, count)

writes  out an  array by  outputting count  number of  consecutive words
starting at location loc.

        REAL ARRAY results [1:max];
                .
                .
        ARRYOUT(resultFile,results[1],max);


TENEX Sail also has the routine:

        CHAROUT(chan#, char)

which outputs a single character to the channel.

The OUT function is generally obsolete now that CPRINT is available.


                               SECTION  6

                                Records




Records are the newest data structure in Sail.  They take us  beyond the
basic part of the language, but  we describe them here in the  hope that
they will  be very useful  to users of  the language.  Sail  records are
similar to those in ALGOL W (see Appendix A for the  differences).  Some
other  languages  that  contain record-like  structures  are  SIMULA and
PASCAL.

Records  can  be  extremely  useful  in  setting  up   complicated  data
structures.   They allow  the  Sail programmer:  1) a  means  of program
controlled storage allocation,  and 2) a  simple method of  referring to
bundles  of  information.  (Location(x)  and  memory[x],  which  are not
discussed here and should be  thought of as liberation from  Sail, allow
one to deal with addresses of things.)

6.1  Declaring and Creating Records

A record  is rather  like an array  that can  have objects  of different
syntactic  types.   Usually  the record  represents  different  kinds of
information  about one  object.  For  example, we  can have  a  class of
records  called  person  that contains  records  with  information about
people for  an accounting  program.  Thus,  we might  want to  keep: the
person's  name, address,  account  number, monetary  balance.   We could
declare a record class thus:

    RECORD!CLASS person (STRING name, address;
                         INTEGER account;
                         REAL balance)

This occurs at declaration level, and the identifier person is available
within the current block -- just like any other identifier.

RECORD!CLASS  declarations do  not actually  reserve any  storage space.
Instead they define  a pattern or template  for the class,  showing what
fields  the  pattern has.   In  the above,  name,  address,  account and
balance are all fields of the RECORD!CLASS person.

To create a record (e.g., when you get the data on an actual person) you
need to call the NEW!RECORD  procedure, which takes as its  argument the
RECORD!CLASS.  Thus,

        rp _ NEW!RECORD (person);

creates a  person, with  all fields  initially 0  (or NULL  for strings,
etc).  Records are  created dynamically by  the program and  are garbage
collected when there is no longer a way to access them.

When  a record  is  created, NEW!RECORD  returns  a pointer  to  the new
record.   This  pointer   is  typically  stored  in   a  RECORD!POINTER.
RECORD!POINTERs are variables which must be declared. The RECORD!POINTER
rp was  used above.  There  is a very  important distinction to  be made
between a RECORD!POINTER and a RECORD.  A RECORD is a block of variables
called fields,  and a RECORD!POINTER  is an entity  that points  to some


RECORD (hence can be thought of as the "name" or "address" of a RECORD).
A  RECORD  has  fields,  but a  RECORD!POINTER  does  not,  although its
associated RECORD may have fields.  The following is a  complete program
that declares a RECORD!CLASS,  declares a RECORD!POINTER, and  creates a
record in the RECORD!CLASS with the pointer to the new record  stored in
the RECORD!POINTER.

    BEGIN
    RECORD!CLASS person (STRING name,address;
                         INTEGER account;
                         REAL balance);
    RECORD!POINTER (person) rp;

    COMMENT program starts here.;
    rp _ NEW!RECORD (person);
    END;


RECORD!POINTERs are usually associated with particular record class(es).
Notice  that  in the  above  program the  declaration  of RECORD!POINTER
mentions the class person:

        RECORD!POINTER (person) rp;

This means that  the compiler will do  type checking and make  sure that
only pointers  to records  of class person  will be  stored into  rp.  A
RECORD!POINTER can be of several classes, as in:

        RECORD!POINTER (person, university) rp;

assuming that we had a RECORD!CLASS university.

RECORD!POINTERs can be of any class if we say:

        RECORD!POINTER (ANY!CLASS) rp;

but declaring  the class(es) of  record pointers gives  compilation time
checking of record class agreement.  This becomes an advantage  when you
have several classes, since the compiler will complain about many of the
simple mistakes you can make by mis-assigning record pointers.



6.2  Accessing Fields of Records

The fields  of records  can be  read/written just  like the  elements of
arrays.   Developing  the above  program  a bit  more,  suppose  we have
created a  new record of  class person, and  stored the pointer  to that
record in  rp.  Then, we  can give the  "person" a name,  address, etc.,
with the following statements.

    person:name[rp] _ "John Doe";
    person:address[rp] _ "101 East Lansing Street";
    person:account[rp] _ 14;
    person:balance[rp] _ 3000.87;

and we could write these fields out with the statement:

  PRINT ("Name is ", person:name[rp], crlf,
        "Address is ", person:address[rp], crlf,


        "Account is ", person:account[rp], crlf,
        "Balance is ", person:balance[rp], crlf);

The syntax for fields has the following features:

       1)  The fields  are available within  the lexical  scope where
   the RECORD!CLASS was declared, and follow ALGOL block structure.

       2)  The fields  in different classes  may have the  same name,
   e.g., parent:name and child:name.

       3)  The  syntax  is  rather  like  that  for  arrays  -- using
   brackets to surround the  record pointer in the same  way brackets
   are used for the array index.

       4)  The fields can  be read or  written into, also  like array
   locations.

       5)  It is necessary to write class:field[pointer] -- i.e., you
   have to  include the name  of the class  (here person) with  a ":"
   before the name of the field.



6.3  Linking Records Together

Notice, in the above example, that as we create the persons, we  have to
store the  pointers to the  records somewhere or  else they  will become
"missing persons".   One way  to do  this would  be to  use an  array of
record  pointers,  allocating as  many  pointers as  we  expect  to have
people.  If the number of people  is not known in advance then  the more
customary approach  is to link  the records together,  which is  done by
using additional fields in the records.

Suppose we upgrade the above example to the following:

    RECORD!CLASS person (STRING name, address;
                 INTEGER account;
                 REAL balance;
                 RECORD!POINTER(ANY!CLASS) next);

Notice now that there is  a RECORD!POINTER field in the  template.  This
may be used  to keep a  pointer to the next  person.  The header  to the
entire list of persons will be kept in a single RECORD!POINTER.

Thus, the  following program  would create  persons dynamically  and put
them into a "linked list" with the newest at the head of the list.  This
technique allows you to write  programs that are not restricted  to some
fixed maximum number of  persons, but instead allocate the  memory space
necessary for a new person when you need it.



    BEGIN
    RECORD!CLASS person (STRING name, address;
        INTEGER account; REAL balance;
        RECORD!POINTER(ANY!CLASS) next);

    RECORD!POINTER (ANY!CLASS) header;


    WHILE TRUE DO
      BEGIN
        STRING s;
        RECORD!POINTER (ANY!CLASS) temp;

        PRINT("Name of next person, CR if done:");
        IF NOT LENGTH(s _ INCHWL) THEN DONE;

        COMMENT put new person at head of list;
        temp _ NEW!RECORD(person);
        COMMENT make a new record;
        person:next[temp] _ header;
        COMMENT the old head becomes the second;
        header _ temp;
        COMMENT the new record becomes the head;

        COMMENT now fill information fields;
        person:name[temp] _ s;
        COMMENT now we can  fill address, account,
        balance if we want...;
      END;

    END;



A very  powerful feature  of record  structures is  the ability  to have
different sets of  pointers.  For example,  there might be  both forward
and backward links (in the  above, we used a forward  link).  Structures
such as binary trees,  sparse matrices, deques, priority queues,  and so
on are natural applications of records, but it will take a  little study
of the  structures in order  to understand how  to build them,  and what
they are good for.

Be warned about the difference between records, record  pointers, record
classes, and the  fields of records: they  are all distinct  things, and
you can get in trouble if you forget it.  Perhaps a simple  example will
show you what is meant:



    BEGIN
    RECORD!CLASS pair (INTEGER i, j);
    RECORD!POINTER (pair) a, b, c, d;

    a _ NEW!RECORD (pair);
    pair:i [a] _ 1;
    pair:j [a] _ 2;
    d _ a;
    b _ NEW!RECORD (pair);
    pair:i [b] _ 1;
    pair:j [b] _ 2;
    c _ NEW!RECORD (pair);
    pair:i [c] _ 1;
    pair:j [c] _ 3;
    IF a = b THEN PRINT( " A = B " );
    pair:j [d] _ 3;
    IF a = c THEN PRINT( " A = C " );
    IF c = d THEN PRINT( " C = D " );
    IF a = d THEN PRINT( " A = D " );
    PRINT( " (A I:", pair:i [a], ", J:",
           pair:j [a], ")" );
    PRINT( " (B I:", pair:i [b], ", J:",
           pair:j [b], ")" );
    PRINT( " (C I:", pair:i [c], ", J:",
           pair:j [c], ")" );
    PRINT( " (D I:", pair:i [d], ", J:",
           pair:j [d], ")" );
    END;

will print:


    A = D  (A I:1, J:3) (B I:1, J:2)
    (C I:1, J:3) (D I:1, J:3)

Note that two RECORD!POINTERs are  only equal if they point to  the same
record (regardless of whether the fields of the records that  they point
to are equal).  At the end of executing the previous example,  there are
3 distinct records, one pointed  to by RECORD!POINTER b, one  pointed to
by RECORD!POINTER  c, and  one pointed  to by  RECORD!POINTERs a  and d.
When the line  that reads: pair:j [d]  3;  is executed, the  j-field of
the record pointed at  by RECORD!POINTER d is  changed to 3, not  the j-
field of  d (RECORD!POINTERs have  no fields).  Since  that is  the same
record  as  the  one  pointed to  by  RECORD!POINTER  a,  when  we print
pair:j [a], we get the value 3, not 2.

Records can  also help  your programs to  be more  readable, by  using a
record as a means of  returning a collection of values from  a procedure
(no Sail  procedure can  return more than  one value).   If you  wish to
return a  RECORD!POINTER, then the  procedure declaration  must indicate
this as an additional  type-qualifier on the procedure  declaration, for
example:

  RECORD!POINTER (person) PROCEDURE maxBalance;
  BEGIN
  RECORD!POINTER (person) tempHeader,
                          currentMaxPerson;
  REAL currentMax;
  tempHeader _ header;


  currentMax _ person:balance [tempHeader];
  currentMaxPerson _ tempHeader;
  WHILE tempHeader _ person:next [tempHeader] DO
  IF person:balance [tempHeader] > currentMax THEN
    BEGIN
      currentMax _ person:balance [tempheader];
      currentMaxPerson _ tempHeader;
    END;
  RETURN(currentMaxPerson);
  END;

This procedure  goes through the  linked list of  records and  finds the
person with the  highest balance.  It then  returns a record  pointer to
the record of  that person.  Thus,  through the single  RETURN statement
allowed, you get both the name of the person and the balance.

RECORD!POINTERs can also be used as arguments to procedures; they are by
default  VALUE  parameters  when  used.   Consider  the  following quite
complicated example:

    RECORD!CLASS pnt (REAL x,y,z);
    RECORD!POINTER (pnt) PROCEDURE midpoint
                         (RECORD!POINTER (pnt) a,b);
    BEGIN
    RECORD!POINTER (pnt) retval;
    retval _ NEW!RECORD (pnt);
    pnt:x [retval] _ (pnt:x [a] + pnt:x [b]) / 2;
    pnt:y [retval] _ (pnt:y [a] + pnt:y [b]) / 2;
    pnt:z [retval] _ (pnt:z [a] + pnt:z [b]) / 2;
    RETURN( retval );
    END;

  ...
  p _ midpoint( q, r );
  ...
While this procedure may appear a  bit clumsy, it makes it easy  to talk
about  such things  as  pnts later,  using  simply a  record  pointer to
represent each pnt.  Another common method for "returning" more than one
thing  from  a procedure  is  to  use REFERENCE  parameters,  as  in the
following example:

    PROCEDURE midpoint (REFERENCE REAL rx,ry,rz;
                        REAL ax,ay,az,bx,by,bz);
    BEGIN
    rx _ (ax + bx) / 2;
    ry _ (ay + by) / 2;
    rz _ (az + bz) / 2;
    END;
        ...
MIDPOINT( px, py, pz, qx, qy, qz, rx, ry, rz, );
        ...

Here the  code for the  procedure looks quite  simple, but there  are so
many arguments  to it that  you can  easily get lost  in the  main code.
Much  of  the confusion  comes  about because  procedures  simply cannot
return  more than  one value,  and the  record structure  allows  you to
return the name of a bundle of information.


                               SECTION  7

                        Conditional Compilation




Conditional compilation is available so that the same source file can be
used to compile slightly different versions of the program for different
purposes.  Conditional compilation  is handled by  the scanner in  a way
similar  to the  handling of  macros.  The  text of  the source  file is
manipulated before it is compiled.  The format is

        IFCR boolean THENC code ELSEC code ENDC

This  construction is  not  a statement  or  an expression.   It  is not
followed by a semi-colon but just appears at any point in  your program.
The ELSEC is optional.  The ENDC must be included to mark the end but no
begin is used.  The code which follows the THENC (and ELSEC if used) can
be any  valid Sail syntax  or fragment of  syntax.  As with  macros, the
scanner is simply manipulating text and does not check that the  text is
valid syntax.

The boolean must be one which  has a value at compile time.   This means
it cannot be any value  computed by your program.  Usually,  the boolean
will be DEFINE'd by a macro.  For example:

        DEFINE smallVersion = <TRUE>;
            . . .
        IFCR smallVersion THENC max _ 10*total;
        ELSEC max _ 100*total; ENDC
            . . .
where  every  difference in  the  program between  the  small  and large
versions  is handled  with a  similar  IFCR...THENC...ENDC construction.
For this construction, the scanner checks the value of the  boolean; and
if it is TRUE, the text following THENC is inserted in the  source being
sent to the inner compiler--otherwise the text is simply thrown away and
the code following the ELSEC (if  any) is used.  Here the code  used for
the  above will  be max  10*total;,  and if  you edit  the  program and
instead

        DEFINE smallVersion = <FALSE>;

the result will be max   100*total;.

The code following the  THENC and ELSEC will  be taken exactly as  is so
that  statements which  need final  semi-colons should  have  them.  The
above format of statement ; ELSEC is correct.

If this feature were not  available then the following would have  to be
used:

        BOOLEAN smallVersion;
        smallVersion _ TRUE;
            ...
        IF smallVersion THEN max _ 10*total
        ELSE max _ 100*total;
            ...

so that a conditional would actually appear in your program.


Some typical uses of conditional compilation are:

       1)  Insertion of  debugging or  testing code  for experimental
   versions  of a  program and  then removal  for the  final version.
   Note that the code  will still be in  your source file and  can be
   turned back on (recompilation  is of course required) at  any time
   that you again need to debug.  When you do not turn  on debugging,
   the code completely disappears from your program but not from your
   source file.

       2)  Maintainence of a single  source file for a  program which
   is to be exported to several sites with minor differences.

   DEFINE sumex = <TRUE>,
          isi = <FALSE>;
           ...
   IFCR sumex THENC docdir _ "DOC"; ENDC
   IFCR isi THENC docdir _ "DOCUMENTATION"; ENDC
             ...

   where only one site is set to TRUE for each compilation.

       3)  "Commenting out" large portions of the program.  Sometimes
   you need  to temporarily  remove a large  section of  the program.
   You can insert  the word COMMENT  preceding every statement  to be
   removed but this is a lot of extra work.  A better way is to use:

   IFCR FALSE THENC
       ...
   <all the code to be "removed">
       ...
   ENDC


                               SECTION  8

                        Systems Building in Sail




Many new  Sail users will  find their first  Sail project  involved with
adding to an already-existing system of large size that has  been worked
on by  many people over  a period of  years.  These systems  include the
speech recognition programs at Carnegie-Mellon, the hand-eye software at
Stanford AI, large  CAI systems at  Stanford IMSSS, and  various medical
programs at SUMEX and NIH.   This section does not attempt to  deal with
these individual systems  in any detail,  but instead tries  to describe
some  of  the features  of  Sail  that are  frequently  used  in systems
building, and are common to all these systems.  The  exact documentation
of these features is given elsewhere; this is intended to be a  guide to
those features.

The Sail language itself is procedural, and this means that programs can
be  broken  down  into  components  that  represent   conceptual  blocks
comprising the system.  The  block structuring of ALGOL also  allows for
local variables, which should be used wherever possible.  The first rule
of systems building is: break the system down into modules corresponding
to conceptual  units.  This is  partly a question  of the design  of the
system--indeed, some systems by  their very design philosophy  will defy
modularity to a certain extent.  As a theory about the representation of
knowledge  in computer  programs, this  may be  necessary;  but programs
should, most people would agree, be as modular "as possible".

Once modularized, most of the parts of the system can be separate files,
and we shall  show below how this  is possible.  Of course,  the modules
will have  to communicate together,  and may have  to share  common data
(global arrays, flags, etc.).   Also, since the modules will  be sharing
the same  core image (or  job), there are  certain Sail  and timesharing
system resources  that will have  to be commonly  shared.  The  rules to
follow here are:

       1)  Make the  various modules of  a system as  independent and
   separate as design philosophy allows.

       2)  Code  them  in  a similar  "style"  for  readability among
   programmers.

       3)  Make the points of interface and communication between the
   programs as clear and explicit as possible.

       4)  Clear  up  questions  about  which  modules  govern system
   resources  (Sail  and  the  timesharing  system),  such  as files,
   terminals, etc.  so  that they are  not competing with  each other
   for these resources.


8.1  The Load Module

The most  effective separation of  modules is achieved  through separate
compilations.  This is done by having two or more separate source files,
which are  compiled separately and  then loaded together.   Consider the
following  design for  an  AI system  QWERT.  QWERT  will  contain three
modules:  a scanner  module XSCAN,  a parser  module PARSE,  and  a main
program QWERT. We give below the three files for QWERT.

First, the QWERT program, contained in file QWERT.SAI:

    BEGIN"QWERT"

    EXTERNAL STRING PROCEDURE XSCAN(STRING S);
    REQUIRE "XSCAN" LOAD!MODULE;

    EXTERNAL STRING PROCEDURE PARSE(STRING S);
    REQUIRE "PARSE" LOAD!MODULE;

    WHILE TRUE DO
        BEGIN
            PRINT("*",PARSE(XSCAN(INCHWL)));
        END;

    END"QWERT";

Notice two features about QWERT.SAI:

       1)  There   are  two   EXTERNAL  declarations.    An  EXTERNAL
   declaration says that  some identifier (procedure or  variable) is
   to be used in the current program, but it will be  found somewhere
   else.  The EXTERNAL causes the  compiler to permit the use  of the
   identifier, as requested, and then to issue a request for a global
   fixup to the LOADER program.

       2)  Secondly, there are two REQUIRE ... LOAD!MODULE statements
   in the program.   A load module  is a file  that is loaded  by the
   loader,  presumably  the  output of  some  compiler  or assembler.
   These REQUIRE  statements cause the  compiler to request  that the
   loader load modules XSCAN.REL and PARSE.REL when we load MAIN.REL.
   This will hopefully satisfy the global requests: i.e.,  the loader
   will find the two procedures in the two mentioned files,  and link
   the programs all together into one "system".

Second, the code for modules XSCAN and PARSE:

    ENTRY XSCAN;
    BEGIN

    INTERNAL STRING PROCEDURE XSCAN(STRING S);
    BEGIN
      ..... code for XSCAN ....
    RETURN (resulting string);
    END;

    END;

and now PARSE.SAI:




    ENTRY PARSE;
    BEGIN

    INTERNAL STRING PROCEDURE PARSE(STRING S);
    BEGIN

      ....code for PARSE....
    RETURN(resulting string);
    END;

    END;

Both of  these modules begin  with an ENTRY  declaration.  This  has the
effect of saying that the program to be compiled is not a "main" program
(there can be only one main program in a core image), and also says that
PARSE is  to be  found as  an INTERNAL  within this  file.  The  list of
tokens after the ENTRY  construction is mainly used for  LIBRARYs rather
than  LOAD!MODULEs, and  we do  not discuss  the difference  here, since
LIBRARYs are not much used  in system building due to the  difficulty in
constructing them.

A few important remarks about LOAD!MODULES:

       1)  The use of LOAD!MODULES depends on the loaders (LOADER and
   LINK10) that are available on the system.  In particular, there is
   no  way  to  associate  an  external  symbol  with   a  particular
   LOAD!MODULE.

       2)  The names  of identifiers are  limited to  six characters,
   and the character set  permissible is slightly less than  might be
   expected.   The symbol  "!" is,  for example,  mapped into  "." in
   global symbol requests.

       3)  The  "semantics" of  a  symbol (e.g.,  whether  the symbol
   names  an integer  or a  string procedure)  is in  no  way checked
   during loading.

Initialization routines in a LOAD!MODULE can be  performed automatically
by  including  a  REQUIRE ...  INITIALIZATION  procedure.   For example,
suppose that  INIT is a  simple parameterless, valueless  procedure that
does the initialization for a given module:

    SIMPLE PROCEDURE INIT;
    BEGIN
       ...initialization code...
    END;


    REQUIRE INIT INITIALIZATION;

will run  INIT prior  to the  outer block  of the  main program.   It is
difficult to control the order in which initializations are done,  so it
is  advisable to  make initializations  that do  not conflict  with each
other.


8.2  Source Files

In addition to the ability to compile programs separately, Sail allows a
single compilation to  be made by inserting  entire files into  the scan
stream during compilation.  The construction:

        REQUIRE "FILENM.SAI" SOURCE!FILE;

inserts the text of file FILENM.SAI into the stream of  characters being
scanned--having the same effect that would be obtained by copying all of
FILENM.SAI into the current file.

One pedestrian use of  this is to divide  a file into smaller  files for
easier editing.  While this can be convenient, it can also unnecessarily
fragment  a  program into  little  pieces without  purpose.   There are,
however, some real purposes  of the SOURCE!FILE construction  in systems
building.  One use is to  include code that is needed in  several places
into one file, then "REQUIRE" that file in the places that it is needed.
Macros are a common example.  For example, a file of  global definitions
might be put into a file MACROS.SAI:

    REQUIRE "<><>" DELIMITERS;
    DEFINE  ARRAYSIZE=<100>,
            NUMBEROFSTUDENTS=<200>,
            FILENAME=<"FIL.DAT">;

A common use of source files is to provide a SOURCE!FILE that links to a
load module: the source file contains the EXTERNAL declarations  for the
procedures (and data)  to be found in  a module, and also  requires that
file as a load module.  Such a file is sometimes called a "header" file.
Consider the file XSCAN.HDR for the above XSCAN load module:

    EXTERNAL STRING PROCEDURE XSCAN(STRING S);
    REQUIRE "XSCAN" LOAD!MODULE;

The use  of header  files ameliorates  some of  the deficiencies  of the
loader:  the header  file  can, for  example, be  carefully  designed to
contain the declarations of  the EXTERNAL procedures and  data, reducing
the likelihood of an  error caused by misdeclaration.  Remember,  if you
declare:

    INTERNAL STRING PROCEDURE XSCAN(STRING S);
    BEGIN ..... END;

in one file and

    EXTERNAL INTEGER PROCEDURE XSCAN(STRING S);

in another, the correct linkages  will not be made, and the  program may
crash quite strangely.


8.3  Macros and Conditional Compilation

Macros, especially those contained in global macro files, can  assist in
system  building.   Parameters,  file   names,  and  the  like   can  be
"macroized".

Conditional compilation also assists in systems building by allowing the
same source  files to do  different things depending  on the  setting of
switches.  For  example, suppose a  file FILE is  being used for  both a
debugging and a "production" version of the same module.  We can include
a definition of the form:

    DEFINE  DEBUGGING=<FALSE>;
    COMMENT false if not debugging;

and then use it

    IFCR DEBUGGING THENC
        PRINT("Now at PROC PR ",I," ",J,CRLF); ENDC

(See  Section 7  on conditional  compilation for  more details.)  In the
above example,  the code  will define the  switch to  be FALSE,  and the
PRINT  statement  will  not  be  compiled,  since  it  is  in  the FALSE
consequent of an  IFCR ...THENC.  In using  switches, it is  common that
there  is a  default setting  that one  generally wants.   The following
conditional  compilation checks  to see  if DEBUGGING  has  already been
defined (or  declared), and if  not, defines it  to be false.   Thus the
default is established.

    IFCR NOT DECLARATION(DEBUGGING) THENC
         DEFINE DEBUGGING=<FALSE>; ENDC

Then, another  file, inserted  prior to this  one, sets  the compilation
mode to get the DEBUGGING version if needed.

Macros  and  conditional  compilation also  allow  a  number  of complex
compile-time operations, such as building tables.  These are  beyond our
discussion  here, except  to  note that  complex macros  are  often used
(overused?) in systems building with Sail.


                               APPENDIX A

                      Sail and ALGOL W Comparison



There are  many variants of  ALGOL.  This Appendix  will cover  only the
main differences between Sail and ALGOL W.

The following are differences in terminology:

ALGOL W                                    Sail

:=           Assignment operator           _
**           Exponentiation operator       ^
=           Not equal                      or NEQ
<=           Less than or equal             or LEQ
>=           Greater than or equal          or GEQ
REM          Division remainder operator   MOD
END.         Program end                   END
RESULT       Procedure parameter type      REFERENCE
str(i|j)     Substrings               str[i+1 for j]
STRING(i) s  String declarations           STRING s
arry(1)      Array subscript               arry[1]
arry (1::10) Array declaration            arry[1:10]


The following are not available in Sail:

ODD  ROUND  ENTIER

TRUNCATE        Truncation is default conversion.

WRITE, WRITEON  Use PRINT statement for both.

READON          Use INPUT, REALIN, INTIN.

Block expressions

Procedure expressions
                Use RETURN statement
                in procedures.

Other differences are:

1)  Iteration variables  and Labels  must be declared  in Sail,  but the
    iteration variable is more general since it can be tested  after the
    loop.

2)  STEP UNTIL cannot be left out in the FOR-statement in Sail.

3)  Sail strings do not have length declared and are not filled out with
    blanks.

4)  EQU not = is used for Sail strings.

5)  The first case in the CASE  statement in Sail is 0 rather than  1 as
    in ALGOL W.  (Note that Sail also has CASE expressions.)


6)  <, =, and > will not work for alphabetizing Sail strings.   They are
    arithmetic operators only.

7)  ALGOL W parameter passing conventions vary slightly from  Sail.  The
    ALGOL W RESULT parameter  is close to the Sail  REFERENCE parameter,
    but  there is  a difference,  in that  the Sail  REFERENCE parameter
    passes an address,  whereas the ALGOL  W RESULT parameter  creates a
    copy of the value during the execution of the procedure.

8)  A  FORWARD  PROCEDURE  declaration  is  needed  in  Sail  if another
    procedure calls an as yet undeclared procedure.  Sail is  a one-pass
    compiler.

9)  Sail uses SIMPLE PROCEDURE, PROCEDURE, and RECURSIVE PROCEDURE where
    ALGOL has only PROCEDURE (equivalent to Sail's RECURSIVE PROCEDURE).

10)  Scalar variables  in Sail are  not cleared on  block entry  in non-
     RECURSIVE procedures.

11)  Outer block arrays in Sail must have constant bounds.

12)  The RECORD syntax is considerably different.  See below.



Sail features (or improvements) not in ALGOL W:

a)  Better string facilities with more flexibility.

b)  More complete RECORD structures.

c)  Use of DONE and CONTINUE statements for easier control of loops.

d)  Assignment expressions for more compact code.

e)  Complete I/O facilities.

f)  Easy interface to machine instructions.



The following  compares Sail  and ALGOL W  records in  several important
aspects.

Aspect          Sail                    ALGOL W
-------------------------------------------------
Declaration     RECORD!CLASS        RECORD
of class

Declaration of  RECORD!POINTER      REFERENCE
record pointer
                Pointers can be     pointers must
                several classes or  be to one
                ANY!CLASS           class

Empty record    Reserved word       Reserved word
                NULL!RECORD         NULL

Fields of record
                Use brackets        Use parens

                Must use            Don't use
                CLASS: before the   class name
                field name          before field


                               REFERENCES



1.  Reiser,  John  (ed.),   Sail,  Memo  AIM-289,   Stanford  Artificial
    Intelligence Laboratory, August 1976.

2.  Frost,  Martin,  UUO Manual  (Second  Edition),  Stanford Artificial
    Intelligence Laboratory Operating Note 55.4, July 1975.

3.  Harvey,  Brian (M.  Frost,  ed.), Monitor  Command  Manual, Stanford
    Artificial  Intelligence  Laboratory  Operating  Note  54.5, January
    1976.

4.  Feldman,  J.A., Low,  J.A., Swinehart,  D.C., Taylor,  R.H., "Recent
    Developments in Sail", AFIPS FJCC 1972, p. 1193-1202.

5.  DECSYTEM10  Assembly   Language  Handbook  (3rd   Edition),  Digital
    Equipment Corporation, Maynard, Massachusetts, 1973.

6.  DECSYSTEM10   Users  Handbook   (2nd  Edition),   Digital  Equipment
    Corporation, Maynard, Massachusetts, 1972.

7.  Myer, Theodore and Barnaby, John, TENEX EXECUTIVE Manual (revised by
    William   Plummer),    Bolt,   Beranek   and    Newman,   Cambridge,
    Massachusetts, 1973.

8.  JSYS  Manual (2nd  Revision), Bolt,  Beranek and  Newman, Cambridge,
    Massachusetts, 1973.


                                 INDEX





!SKIP!  46

&  18

ALGOL  74
allocation  23
Altmode  46
ANY!CLASS  62
Arguments  31
array  6, 10
arrays  23, 25, 59
ARRCLR  24
ARRYIN  52, 59
ARRYOUT  52, 60
assignment expressions  16
assignment operator  16
Assignment statements  7

BEGIN  3
binary format files  59
bits  56
block  3
block name  21
blocks  15, 21
BOOLEAN  4
boolean expression  12
break character  42, 46, 58
break tables  42
built-in procedures  9, 30

CASE expressions  18
CFILE  52
channel  52, 58
channel number  47
CHARIN  59
CHAROUT  60
Commenting  68
compile time  23
compound statement  15
Conditional compilation  67
conditional expressions  17
conditionals  11
connected directory  56
constants  5
CONTINUE  28
control statements  11
controlling terminal  46, 56
CPRINT  60
crlf  47
CVD  9

data  59
deallocation  23


debugging  68
Declarations  3
DEFINE  38
delimiters  38
directory devices  47, 50
DIRST  57
DO...UNTIL  26
DONE  28
dynamic  23

ELSEC  67
emulator  1
END  3
end-of-file  58, 60
ENDC  67
ENTER  50
ENTRY  70
eol  47
EQU  13, 18
equality  13
error handling  54
expression  7, 10
expressions  15
EXTERNAL  46, 70

FALSE  4
fields  61
file bytepointer  59
file name  50
files  47
flag specification  56
FOR statement  24
format  6
FORWARD  33
free format  6

garbage collections  19
GETBREAK  42
GETCHAN  48
GJINF  57
global  22
GTJFN  55
GTJFNL  55

half word format  56

I/O  46
identifiers  5
IF..THEN statement  11
IFCR  67
INCHWL  9, 46
indefinite iteration  26
INDEXFILE  54
initialization  23
Initialization routines  71
INPUT  42, 58
input/output  46, 47
INTEGER  4
INTIN  59


INTSCAN  45
INTTY  46
iteration variable  24

JFNS  57

LENGTH  18
line terminators  44
line-editing  46
LOAD!MODULE  70
LOADER  70
local  22
login directory  56
LOOKUP  50
LOP  18
lowercase  6

macro expansion  38
macros  38
modularity  69
MTAPE  52
multi-dimensioned arrays  7
multiple file designators  54

nested  14, 22
NEW!RECORD  61
NUL character  20
NULL  5

octal representation  56
OPEN  48
OPENFILE  52
order of evaluation  16
outer block  3
OWN  23

PA1050  1
parallel arrays  7
parameter list  31
parameterized procedure  31
parenthesized  17
predeclared identifiers  5
PRINT  9
PRINT statement  39
procedure  30
procedure body  33
procedure call  30

random I/O  59
RCHPTR  60
read error  58
REAL  4
REALIN  59
REALSCAN  45
RECORD!CLASS  61
RECORD!POINTER  61
Records  61
RECURSIVE  23, 33
REFERENCE  37


reinitialization  23
RELEASE  49
RENAME  50
reserved words  3, 5
RETURN statement  33
runtime  23

scalar variables  23
SCAN  42
scanner  38
SCHPTR  60
scope of the variable  22
search path  56
semi-colon  12
sequential I/O  59
SETBREAK  42
SETFORMAT  21
SETINPUT  52
SETPL  58
SETPRINT  47
side-effect  36
SIMPLE  33
SINI  59
SOS line numbers  43
SOURCE!FILE  72
SQRT  9
Statements  3
statements  7
Storage allocation  23
STRING  4
string descriptor  19
STRING operators  18
string space  19
strings  42
subscripts  7
substrings  19

tables  21
Teletype I/O  46
TENEX Sail  1
THENC  67
TOPS-10 Sail  1
TRUE  4
TTY:  56
type conversion  9
typed procedures  35

untyped procedures  35
uppercase  6, 32, 43, 46
USETI  52
USETO  52

VALUE  37
variables  5, 22

WHILE...DO  26
WORDIN  52, 59
WORDOUT  52, 60