F.5.1. S/SL: Notation

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

F.5.2. S/SL: Programs

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

A program is:

    [inputDefinition]       [outputDefinition]
    [inputOutputDefinition]
    [errorDefinition]       {typeOrMechanismDefinition}
    RULES                   {rule}             
    END

F.5.3. S/SL: Input and Output Definitions

An inputDefinition is:

  INPUT  ":"        {tokenDefinition} ";"

An outputDefinition is:

  OUTPUT ":"        {tokenDefinition} ";"

An inputOutputDefinition is:

  INPUT OUTPUT ":"  {tokenDefinition} ";"

A tokenDefinition is:

  [string] ["=" tokenValue]

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

The optional string which may be given in a 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 tokenDefinition. The 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 inputDefinition section and the last token defined in the outputDefinition section. In this way the default input-output token values are unique with respect to both input tokens and output tokens.

F.5.4. S/SL: Error Signals

An errorDefinition is:

  ERROR ":"         {errorSignalDefinition} ";"

An errorSignalDefinition is:

  id ["=" errorValue]

Each 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 errorSignalDefinition. The 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).

F.5.5. S/SL: 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 typeOrMechanismDefinition is one of:

• typeDefinition

• mechanismDefinition

F.5.6. S/SL: Types.

A typeDefinition is:

  TYPE id ":"   {valueDefinition} ";"

A valueDefinition is:

  id ["=" value]

Each 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 valueDefinition defines a valueId in the type. An integer value is associated with each valueId for use in the implementation of the S/SL program. This value may be optionally specified in each 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 valueDefinition in a type is zero.

F.5.7. S/SL: Mechanisms.

A mechanismDefinition is:

  MECHANISM id ":"     {operationDefinition} ";"

Each mechanismDefinition defines the set of semantic operations associated with a semantic mechanism. The 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 operationDefinition is one of:

1. id

2. id "(" typeId")"

3. id ">>" typeId

4. id "(" typeId ")" ">>" typeId

Each operationDefinition defines a semantic operation associated with the mechanism.

• Form 1 defines an update semantic operation, which causes an update to the semantic data structure.

• Form 2 defines a parameterized update operation, which uses the parameter value to update the semantic data structure. The typeId gives the type of the parameter and can be any previously defined type.

• 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 typeId gives the type of the result and can be any previously defined type.

• Form 4 defines a parameterized choice operation. The first typeId gives the parameter type, the second the result type. Each can be any previously defined type.

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

F.5.8. S/SL: Rules

A rule is one of:

1. id ":" {action} ";"

   
   
   

2. id ">>" typeId ":" {action} ";"

   
   
   

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.

• Form 1 defines a procedure rule which can be invoked using a call action.

• 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.

F.5.9. S/SL: Actions

An action is one of the following:

1. inputToken

2. "." outputToken

3. "#" errorId

4. "{" {action} "}"

5. ">"

6. "[" { "|" inputToken {"," inputToken} ":" {action} } [ "|" "*" ":" {action} ] "]"

7. "@" procedureRuleId

8. ">>"

9. "[" "@" choiceRuleId {"|" valueId {"," valueId} ":" {action} } ["|" "*" ":" {action} ] "]"

10. ">>" valueId

11. updateOpId

12. parameterizedUpdateOpId "(" valueId ")"

13. "[" choiceOpId {"|" valueId {"," valueId} ":" {action} } ["|" "*" ":" {action} ] "]"

14. "[" parameterizedChoiceOpId "(" valueId ")" "|" valueId {"," valueId} ":" {action} } ["|" "*" ":" {action} ] "]"

• 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 inputToken may be an inputTokenId, an inputOutputTokenId, an inputTokenString, an inputOutputTokenString, or a question mark (“?”). The question mark is a special token which matches any input token.

• Form 2 denotes emission of an output token to the output stream. The outputToken may be an outputTokenId, an inputOutputTokenId, an outputTokenString or an inputOutputTokenString.

• Form 3 denotes the emission of the specified error signal to the error stream.

• 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.

• 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 inputToken label can be an inputTokenId, an inputOutputTokenId, an inputTokenString or an 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).

• 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.

• 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).

• 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.

• 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).

• 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.

• 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.

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).