%% \section{S/SL Language}

The information in this appendix is based on 
``Specification of S/SL: Syntax/Semantic Language'' by 
J.R. Cordy and R.C. Holt, December 1979 (Revised March 1980).
Copyright (C) 1979, 1980 by the  University of  Toronto.

This appendix describes the S/SL language which is used
within several scanners of the router system; rfc-822
object token scanner, and zmsh script language scanner
to name the most important ones.

S/SL is a programming language developed at
the Computer Systems Research Group,
University of Toronto as a tool for constructing compilers.
It has been used to implement scanners, parsers, semantic
analyzers, storage allocators and machine code generators.
S/SL  has  been  used  to implement compilers for Euclid, PT
Pascal and Speckle, a PL/1 subset.


\section{Introduction}

S/SL is a procedure-based variable-free programming 
language in which the program logic is  stated  using  a  small
number  of  simple  control constructs.  It accesses data in
terms of a set of operations organized into  data-management
modules  called  mechanisms.   The interface to these 
mechanisms is defined in S/SL but their implementation is  hidden
from the S/SL program.

S/SL has one input stream and one output stream, each of
which is strictly sequential.  These streams  are  organized
into ``tokens'' each of which is read and written as a unit.
An auxiliary output stream for  error  diagnostics  is  also
provided.




\section{Identifiers, Strings and Integers}

An  S/SL identifier may consist of any string of up to 50
letters, digits and underscores (\_) beginning with a letter.
Upper  and  lower  case  letters are considered identical in
S/SL, hence {\tt aa}, {\tt aA}, {\tt Aa} and {\tt AA} 
all represent the same identifier.  {\tt INPUT}, {\tt OUTPUT}, 
{\tt ERROR}, {\tt TYPE}, {\tt MECHANISM}, {\tt RULES}, 
{\tt DO}, {\tt OD}, {\tt IF}, {\tt FI}, {\tt END} 
and their various lower case forms are  keywords
of  S/SL and must not be used as identifiers in an S/SL 
program.

An S/SL string is any sequence of characters not  
including a quote surrounded by quotes (").

Integers  may be signed or unsigned and must lie within a
range defined by  the  implementation.   For  example,  this
range could be -32767 to 32767 on the PDP-11.

Identifiers, keywords,  strings  and  integers  must not
cross line boundaries.  Identifiers, keywords  and  integers
must not contain embedded blanks.




\section{Comments}

A  comment consists of the character ``\%'' (which is not in
a string) and the characters to the right of it on a  source
line.




\section{Character Set}

Since  not all of the special characters used in S/SL are
available on all machines,  the  following  alternatives  to
special characters are allowed.
\begin{itemize}
\item {\tt !} for {\tt $\|$}
\item {\tt DO} for {\tt \{}
\item {\tt OD} for {\tt \}}
\item {\tt IF} for {\tt [}
\item {\tt FI} for {\tt ]}
\end{itemize}





\section{Source Program Format}

S/SL programs are free format; that is, the identifiers,
keywords, strings, integers  and  special  characters  which
make  up  an  S/SL program may be separated by any number of
blanks, tab characters, form feeds and  source  line  bound-
aries.




\section{Notation}

The      following  sections  define  the  syntax  of  S/SL.
Throughout the following, {\tt \{item\}} means zero or more  of the
item,  and {\tt [item]} means the item is optional.  The abbreviation 
{\tt id} is used for identifier.


\subsection{Programs}

An S/SL program consists of a set of definitions followed
by a set of rules.

A program is:
\begin{verbatim}
        [inputDefinition]               [outputDefinition]
        [inputOutputDefinition]
        [errorDefinition]               {typeOrMechanismDefinition}
        RULES                           {rule}             
        END
\end{verbatim}


\subsection{Input and Output Definitions}

An {\tt inputDefinition} is:
\begin{verbatim}
        INPUT   ":"                      {tokenDefinition} ";"
\end{verbatim}

An {\tt outputDefinition} is:
\begin{verbatim}
        OUTPUT  ":"                      {tokenDefinition} ";"
\end{verbatim}


An {\tt inputOutputDefinition} is:
\begin{verbatim}
         INPUT OUTPUT ":"        {tokenDefinition} ";"
\end{verbatim}


A {\tt tokenDefinition} is:
\begin{verbatim}
         id [string] ["=" tokenValue]
\end{verbatim}


The {\tt inputDefinition} section defines the input  tokens  to
the  S/SL program.  The {\tt outputDefinition} section defines the
output tokens of  the  program.   The  {\tt inputOutputDefinition}
section defines those tokens which are both input tokens and
output tokens of the program.  Tokens already defined in the
{\tt inputDefinition} or  {\tt outputDefinition} sections
must not be
redefined in the {\tt inputOutputDefinition section.}

The optional string which may be given in a {\tt tokenDefinition}
is  a synonym for the token identifier and can be used
in place of the identifier anywhere in the S/SL program.

Each input and output token is assigned an integer  value
for  use  in  the  implementation of the S/SL program.  This
value may be optionally specified in  each  {\tt tokenDefinition}.
The {\tt tokenValue} may  be  specified  as an integer or as the
value of any previously defined identifier  or  string.   If
omitted,  the value assigned to the token is the value associated with 
the previous token in the class plus one. The
default  value associated with the first input token and the
first output token is zero.  The  default  value  associated
with the first input-output token is the maximum of the last
token defined in the {\tt inputDefinition} section  and  the    last
token  defined in the {\tt outputDefinition} section.    In this way
the  default  input-output  token  values  are  unique  with
respect to both input tokens and output tokens.




\subsection{Error Signals}

An {\tt errorDefinition} is:
\begin{verbatim}
         ERROR  ":"                       {errorSignalDefinition} ";"
\end{verbatim}

An {\tt errorSignalDefinition} is:
\begin{verbatim}
         id ["=" errorValue]
\end{verbatim}

Each {\tt errorSignalDefinition} defines an error signal  which
can be signalled by the S/SL program.  An integer error code
value is associated with each errorId for use in the  
implementation of the S/SL program.     This value may be optionally
specified in each {\tt errorSignalDefinition}.  The {\tt errorValue} may
be specified as an integer or as the value of any previously
defined identifier or string.  The default value  associated
with an error signal is the value associated with the 
previous error signal plus one.  The default value for the  first
error signal is 10 (errors 0 to 9 are reserved for S/SL system use).




\subsection{Type and Mechanism Definitions}

Type and mechanism definitions may be grouped and  inter-
mixed  to reflect the association of types and the operation
definitions which use them.

A {\tt typeOrMechanismDefinition} is one of:
\begin{itemize}
\item {\tt typeDefinition}
\item {\tt mechanismDefinition}
\end{itemize}





\subsubsection{Types.}

A {\tt typeDefinition} is:
\begin{verbatim}
         TYPE id ":"                      {valueDefinition} ";"
\end{verbatim}


A {\tt valueDefinition} is:
\begin{verbatim}
         id ["=" value]
\end{verbatim}


Each {\tt typeDefinition} defines a type of values for  use  as
the  parameter  or result type of a semantic operation or as
the result type of a rule.

Each {\tt valueDefinition} defines a {\tt valueId} in the  type. An
integer value is associated with each {\tt valueId} for use in the
implementation of the  S/SL  program.   This  value  may  be
optionally specified in each {\tt valueDefinition}.  The value may
be specified as an integer or as the value of any previously
defined identifier or string.  The default value assigned to
a value identifier is the value associated with the previous
value  identifier  plus  one.   The default value associated
with the first {\tt valueDefinition} in a type is zero.


\subsubsection{Mechanisms.}

A {\tt mechanismDefinition} is:
\begin{verbatim}
         MECHANISM    id    ":"         {operationDefinition} ";"
\end{verbatim}

Each {\tt mechanismDefinition}  defines  the  set        of semantic
operations associated with a semantic mechanism.  The 
{\tt mechanismId} itself is unused in the S/SL program.  However, 
operation identifiers associated with a mechanism are by 
convention expected to begin with the mechanism identifier.

An {\tt operationDefinition} is one of:
\begin{enumerate}
\item {\tt id}
\item {\tt id "(" typeId")"}
\item {\tt id ">>" typeId}
\item {\tt id "(" typeId ")" ">>" typeId}
\end{enumerate}


Each {\tt operationDefinition} defines  a  semantic operation
associated with the mechanism.
\begin{itemize}
\item Form 1 defines  an         update  semantic  operation,  which
causes an update to the semantic data structure.
\item Form 2 defines a parameterized update operation, which
uses the parameter value to update the semantic data  
structure.  The {\tt typeId} gives the type of the parameter and can be
any previously defined type.
\item Form 3  defines  a         choice  semantic  operation,  which
returns  a  result  value obtained from the current state of
the semantic mechanism, which is used as the selector  in  a
semantic  choice.   The  {\tt typeId} gives the type of the result
and can be any previously defined type.
\item Form 4 defines a parameterized choice  operation. The
first {\tt typeId} gives the parameter type, the second the result
type.  Each can be any previously defined type.
\end{itemize}

Choice operations  (forms 3 and 4 above)  may  be
invoked only as the selector in a semantic choice.




\subsection{Rules}

A rule is one of:
\begin{enumerate}
\item {\tt id     ":"           \{action\} ";"}
\item {\tt id ">>"  typeId  ":" \{action\} ";"}
\end{enumerate}


The     rules  define  the  subroutines and functions of the
S/SL program.  Rules may call one  another  recursively.   A
rule  need  not  be defined before it is used.  Execution of
the program begins with the first rule.
\begin{itemize}
\item Form 1 defines a procedure rule which  can         be  invoked
using a call action.
\item Form 2 defines  a  choice rule which returns a result
value  of  the  specified  type.   The  {\tt typeId}    can  be  any
previously  defined  type.  Choice rules may only be invoked
as the selector in a rule choice.
\end{itemize}



\subsection{Actions}

An action is one of the following:
\begin{enumerate}
\item 
\begin{verbatim}
inputToken
\end{verbatim}
\item 
\begin{verbatim}
"." outputToken
\end{verbatim}
           
\item 
\begin{verbatim}
"#" errorId
\end{verbatim}
\item 
\begin{verbatim}
"{" {action} "}"
\end{verbatim}
\item 
\begin{verbatim}
">"
\end{verbatim}
\item 
\begin{verbatim}
"[" { "|" inputToken {","    inputToken} ":" {action} }
                [ "|" "*" ":" {action} ] "]"
\end{verbatim}
\item 
\begin{verbatim}
"@" procedureRuleId
\end{verbatim}
\item 
\begin{verbatim}
">>"
\end{verbatim}
\item 
\begin{verbatim}
"[" "@" choiceRuleId {"|" valueId {"," valueId} ":" {action} }
                ["|" "*" ":" {action} ] "]"
\end{verbatim}
                  
\item 
\begin{verbatim}
">>" valueId
\end{verbatim}
\item 
\begin{verbatim}
updateOpId
\end{verbatim}
\item 
\begin{verbatim}
parameterizedUpdateOpId "(" valueId ")"
\end{verbatim}
\item 
\begin{verbatim}
"[" choiceOpId {"|"     valueId {"," valueId} ":" {action} }
                ["|" "*" ":" {action} ] "]"
\end{verbatim}
\item 
\begin{verbatim}
"["     parameterizedChoiceOpId "(" valueId ")"
                "|" valueId {"," valueId} ":" {action} }
                ["|" "*" ":" {action} ] "]"
\end{verbatim}
\end{enumerate}


\begin{itemize}
\item Form 1 is an input action.         The next input token is  to
be  accepted  from  the  input stream.  If it is not the one
specified, a syntax error is flagged.  The {\tt inputToken} may be
an {\tt inputTokenId}, an {\tt inputOutputTokenId}, an {\tt inputTokenString},
an {\tt inputOutputTokenString}, or  a  question  mark  ({\tt ?}).
The question  mark      is  a  special token which matches any input
token.
\item Form 2 denotes emission of an output token to the output  stream.   
The {\tt outputToken} may be an {\tt outputTokenId}, an
{\tt inputOutputTokenId}, an {\tt outputTokenString} or an
{\tt inputOutputTokenString}.
\item Form 3 denotes the emission of the specified error signal to the error stream.
\item Form 4 is a cycle or loop.         Execution  of  the  actions
inside  the  cycle  is repeated until one of its cycle exits
(form 5) or a return (forms 8 and 10)  is       encountered.
A  cycle  exit  causes  execution  to continue following the
nearest enclosing cycle.   The  cycle  exit  action  is  not
allowed outside of a cycle.
\item Form 6 is an input token choice.  The next token in the
input stream is examined and execution  continues  with  the
first  action  in  the  alternative labelled with that input
token.  The matched input token is accepted from  the  input
stream.

Each {\tt inputToken} label  can  be  an {\tt inputTokenId},  an
{\tt inputOutputTokenId}, an {\tt inputTokenString} or an 
{\tt inputOutputTokenString}.  A label can not be repeated nor appear 
on more than one alternative.

The alternative labelled with an  {\tt *}  is  the  otherwise
alternative.   If the next input token does not match any of
the alternative labels of the  choice,  execution  continues
with  the first action in the otherwise alternative.  If the
otherwise alternative is  taken,  the  input  token  is  not
accepted  from  the  input  stream,  but remains as the next
input token.  After execution  of  the  last  action  in  an
alternative of the choice, execution continues following the
choice.

If the next input token does not match any of the  
alternative     labels  and  no  otherwise alternative is present, a
syntax error is flagged.  For parsers written in  S/SL,  the
default  error  handling  strategy  is  to repeat the choice
after modifying the input stream such that  the  next  input
token  matches  the  first alternative.  For compiler phases
other than parsers, continued execution  is  undefined  (the
implementation aborts).
\item Form 7 is a call to a procedure rule.  Execution 
continues at the first action in the specified rule.  When 
execution       of the called rule is completed, either by executing
the last action in the rule  or  by  encountering  a  return
action  (form 8), execution is resumed following the call.
\item Form 8 is a return action.         It causes a return from the
procedure  rule  in  which it appears.  A procedure rule may
return explicitly by executing a return action or implicitly
by  reaching the end of the rule.  A procedure rule must not
contain a valued return (form 10).
\item Form 9 is a rule choice.  The specified choice rule  is
called  and  returns  a  value  by executing a valued return
action (form 10).  The returned value is  used   to  make  a
choice  similar  to  an input token choice (form 6 above).
Execution continues with the first action of the alternative
whose  label  matches  the  returned  value.  If none of the
alternative labels matches the value, the otherwise 
alternative  is  taken.   Following execution of the last action in
the chosen alternative, execution  continues  following  the
choice.

Each     alternative  label in a rule choice must be a value
of the result type of the choice rule.  A label can  not  be
repeated nor appear on more than one alternative.
\item Form 10 is a valued return action.         The specified value
is returned as the result of the choice rule  in  which  the
action appears.  The value must be of the result type of the
choice rule.  A choice rule may return only by  executing  a
valued return action.  A choice rule must not return 
implicitly by reaching the end of the rule.  It must not contain a
non-valued return (form 8).
\item Form 11 is the invocation of an update semantic 
operation.  Similarly, form 12 is the invocation of a 
parameterized  update  operation.  The parameter value, which must be
of the operation's parameter type, is supplied to the  
invocation of the operation.
\item Form 13 is  a  semantic  choice.  The specified choice
semantic operation is invoked and the returned value used to
make  a  choice  similar  to an input token choice (form 6
above).  Execution continues with the first  action  of  the
alternative whose label matches the returned value.  If none
of the alternative labels matches the value,  the  otherwise
alternative  is  taken.   Following  execution  of  the last
action in the chosen alternative, execution  continues  
following       the  choice.  Similarly, form 14 is a parameterized
semantic choice.  The parameter value, which must be of  the
operation's parameter type, is provided to the invocation of
the choice operation.
\end{itemize}

Each alternative label in a semantic     choice  must  be  a
value  of  the result type of the choice operation.  A label
can not be repeated nor appear on more than one alternative.

If the returned value in a rule choice or semantic choice
does not match any of the alternative labels and  no  
otherwise  alternative  is  present, continued execution is 
undefined (the implementation aborts).




\subsection{The Syntax of S/SL}

A program is:
\begin{verbatim}
     [inputDefinition]     [outputDefinition]
     [inputOutputDefinition]
     [errorDefinition]     {typeOrMechanismDefinition}
     RULES                 {rule}                  
     END
\end{verbatim}


An {\tt inputDefinition} is:
\begin{verbatim}
     INPUT ":"                   {tokenDefinition} ";"
\end{verbatim}


An {\tt outputDefinition} is:
\begin{verbatim}
     OUTPUT ":"                  {tokenDefinition} ";"
\end{verbatim}


An {\tt inputOutputDefinition} is:
\begin{verbatim}
     INPUT OUTPUT ":"            {tokenDefinition} ";"
\end{verbatim}


A {\tt tokenDefinition} is:
\begin{verbatim}
     id [string] ["=" tokenValue]
\end{verbatim}

An {\tt errorDefinition} is:
\begin{verbatim}
     ERROR      ":"       {errorSignalDefinition} ";"
\end{verbatim}

An {\tt errorSignalDefinition} is:
\begin{verbatim}
     id ["=" errorValue]
\end{verbatim}

A {\tt typeOrMechanismDefinition} is one of:
\begin{enumerate}
\item {\tt typeDefinition}
\item {\tt mechanismDefinition}
\end{enumerate}


A {\tt typeDefinition} is:
\begin{verbatim}
     TYPE id ":"                  {valueDefinition} ";"
\end{verbatim}

A {\tt valueDefinition} is:
\begin{verbatim}
     id ["=" value]
\end{verbatim}


A {\tt mechanismDefinition} is:
\begin{verbatim}
     MECHANISM    id    ":" {operationDefinition} ";"
\end{verbatim}


A rule is one of:
\begin{enumerate}
\item 
\begin{verbatim}
id ":" {action} ";"
\end{verbatim}
\item 
\begin{verbatim}
id ">>" typeId  ":" {action} ";"
\end{verbatim}
\end{enumerate}


An action is one of the following:
\begin{enumerate}
\item 
\begin{verbatim}
inputToken
\end{verbatim}
\item 
\begin{verbatim}
"." outputToken
\end{verbatim}
\item 
\begin{verbatim}
"#" errorId
\end{verbatim}
\item 
\begin{verbatim}
"{" {action} "}"
\end{verbatim}
\item 
\begin{verbatim}
">"
\end{verbatim}
\item 
\begin{verbatim}
"["     {"|" inputToken {"," inputToken} ":" {action} }
                ["|" "*" ":" {action} ] "]" 
\end{verbatim}
\item 
\begin{verbatim}
"@" procedureRuleId
\end{verbatim}
\item 
\begin{verbatim}
">>"
\end{verbatim}
             
\item 
\begin{verbatim}
"[" "@" choiceRuleId {"|" valueId {"," valueId} ":" {action} }
                ["|" "*" ":" {action} ] "]" 
\end{verbatim}
\item 
\begin{verbatim}
">>" valueId
\end{verbatim}
\item 
\begin{verbatim}
updateOpId
\end{verbatim}
\item 
\begin{verbatim}
parameterizedUpdateOpId "(" valueId ")"
\end{verbatim}
\item 
\begin{verbatim}
"[" choiceOpId {"|" valueId {"," valueId} ":" {action} }
                ["|" "*" ":" {action} ] "]"
\end{verbatim}
\item 
\begin{verbatim}
"["     parameterizedChoiceOpId  "(" valueId ")"
                {"|" valueId {"," valueId} ":" {action} }
                ["|" "*" ":" {action} ] "]"
\end{verbatim}
\end{enumerate}
