This is sather.info, produced by makeinfo version 4.2 from
sather.texinfo.

INFO-DIR-SECTION Sather
START-INFO-DIR-ENTRY
* sather: (sather).	The Sather Specification.
END-INFO-DIR-ENTRY

This file describes the Sather language.

Copyright (C) 1995 by International Computer Science Institute This
file is part of the GNU Sather package. It is free software; you may
redistribute  and/or modify it under the terms of the  GNU General
Public License (GPL)  as  published  by the  Free  Software
Foundation;  either version 2 of the license, or (at your option) any
later version.  This  program  is distributed  in the  hope that it
will  be  useful, but WITHOUT ANY WARRANTY without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
Doc/GPL for more details.  The license text is also available from:
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA ---------->  Please email comments to
<bug-sather@gnu.org>  <----------


File: sather.info,  Node: Top,  Prev: (dir),  Up: (dir)



This document describes the Sather 1.0 language, as implemented by the
Sather 1.0.7 compiler.

* Menu:

* Introduction::
* Types and Classes::
* Class Elements::
* Statements::
* Expressions::
* Lexical Structure::
* Special Features::
* Built-in Classes::
* Interfacing with other Languages::
* Acknowledgements::
* Concept Index::
* Keyword and Built-in Index::


File: sather.info,  Node: Introduction,  Next: Types and Classes,  Prev: Top,  Up: Top

Introduction
************

Sather is an object-oriented language that supports highly efficient
computation, powerful abstractions for encapsulation and code reuse, a
flexible interactive development environment, and constructs for
improving code correctness. It has statically-checked strong typing,
multiple inheritance, explicit subtyping which is independent of
implementation inheritance, parameterized types, dynamic dispatch,
iteration abstraction, higher-order routines and iters, garbage
collection, exception handling, assertions, preconditions,
postconditions, and class invariants. The development environment
integrates an interpreter, a debugger, and a compiler. Sather code can
be compiled into C code and can efficiently link with C object (".o")
files. This document is a terse but precise specification of Sather
1.0. "The Sather 1.0 Tutorial" presents more examples and motivations.

Data structures in Sather are constructed from _objects_, each of which
has a specific _concrete type_ that determines the operations that may
be performed on it. The implementation of concrete types is defined by
textual units called _classes_.  _Abstract types_ specify a set of
operations without providing an implementation and correspond to sets
of concrete types.  Sather programs consist of classes and abstract
type specifications.  Each Sather variable has a declared type which
determines the types of objects it may hold. Classes define the
following _features: object attributes_ which make up the internal
state of objects, _shared_ and _constant_ attributes which are shared
by all objects of a type, _routines_ which perform operations on
objects, and _iters_ which encapsulate iteration. Features may be
declared _private_ to allow only the class in which they appear to
access them. Accessor routines are automatically defined for reading
object, shared, and constant attributes and for writing object and
shared attributes. The set of non-private routines and iters in a class
define the _interface_ of the corresponding type. Abstract types
directly specify their interfaces. Routine and iter definitions consist
of _statements_ and these are constructed from _expressions_. There are
special _literal expressions_ for boolean, character, string, integer,
and floating point objects.

The following sections describe each of these constructs in turn. Most
sections begin with an example of a syntactic construct followed by
corresponding grammar rules. Multi-line examples are indented after the
first line and three dots "..." indicate code that has been left out
for clarity.

The grammar rules are expressed in a variant of Backus-Naur form.
Non-terminal symbols are represented by strings of letters and
underscores in an italic font and begin with a letter.  The nonterminal
symbol on the left-hand side of a grammar rule is followed by a double
arrow "=>" and the right-hand side of the rule. The terminal symbols
consist of Sather keywords and special symbols and are typeset in the
`Courier' font. Vertical bars "...|..." separate alternatives,
parentheses "(...)" are used for grouping, square brackets "[...]"
enclose optional clauses and braces "{...}" enclose clauses which may
be repeated zero or more times.

Certain conditions are described as _fatal errors_. These conditions
should never occur in correct programs and all implementations must be
able to detect them. For efficiency reasons, however, implementations
may provide the option of disabling checking for certain conditions.


File: sather.info,  Node: Types and Classes,  Next: Class Elements,  Prev: Introduction,  Up: Top

Types and Classes
*****************

There are three kinds of objects in Sather: _value objects_ (e.g.
integers), _reference objects_ (e.g.  strings) and _bound objects_
(Sather's version of closures). The corresponding types: _value_,
_reference_, and _bound_ types, are called concrete types. Abstract
types represent sets of concrete types. _External types_ specify
interfaces to other languages.

The _type graph_ for a program is a directed acyclic graph that is
constructed from the program's source text. Its nodes are types and its
edges represent the _subtype_ relationship. If there is a path in this
graph from a type t1 to a type t2, we say that t2 is a _subtype_ of t1
and that t1 is a _supertype_ of t2. Subtyping is reflexive; any type is
a subtype of itself. Only abstract and bound types can be supertypes
(*note Abstract type definitions:: and *note Bound routine and iter
creation expressions::).

Every Sather variable has a declared type. The fundamental typing rule
is: AN OBJECT CAN ONLY BE HELD BY A VARIABLE IF THE OBJECT'S TYPE IS A
SUBTYPE OF THE VARIABLE'S TYPE. It is not possible for a program which
compiles to violate this rule (i.e. Sather is _statically type-safe_).

Operations are performed on objects by calling _routines_ (*note
Routine definitions::) and _iters_ (*note Iter definitions::) on them.
The _signature_ of a routine consists of its name, the types of its
arguments, if any, and its return type, if any.  Iter signatures
additionally specify that certain arguments are marked "!". This means
that they will be re-evaluated on each iteration through a loop (*note
Iter definitions::).

We say that the routine or iter signature F _conflicts_ with G when

  1. F and G have the same name,

  2. F and G have the same number of arguments,

  3. F and G either both return a value or neither does,

  4. and each argument type in F is either equal to the corresponding
     argument type in G or one of the two types is either abstract or
     bound.

We say that the routine or iter signature F _conforms_ to G when

  1. F and G have the same name,

  2. F and G have the same number of arguments,

  3. the type of each argument of G is a subtype of the corresponding
     argument of F (i.e. _contravariant_ conformance) and for
     corresponding arguments of iters, either both are marked "!" or
     neither is,

  4. F and G either both return a value or neither does,

  5. and if F and G return values, then the return type of F is a
     subtype of the return type of G.

The set of routines and iters that may be called on a type is called the
_interface_ of that type.  A type interface may not contain conflicting
signatures. An interface I1 conforms to an interface I2 if for every
routine or iter f2 in I2 there is a unique conforming routine or iter
f1 in I1. The basic subtyping rule is: "THE INTERFACE OF EACH TYPE MUST
CONFORM TO THE INTERFACES OF EACH OF ITS SUPERTYPES."  This ensures
that calls made on a type can be handled by any of its subtypes.

* Menu:

* Sather source files::
* Abstract type definitions::
* Classes::
* Type specifiers::


File: sather.info,  Node: Sather source files,  Next: Abstract type definitions,  Prev: Types and Classes,  Up: Types and Classes

Sather source files
===================

Example:

     type $COUNTRY is ... end; class USA < $COUNTRY is ... end;

Syntax:

     SOURCE_FILE => [ ABSTRACT_TYPE_DEFINITION | CLASS ]
        { ; [ ABSTRACT_TYPE_DEFINITION | CLASS ] }

Sather source files consist of semicolon separated lists of abstract
type definitions and classes. Abstract types specify interfaces without
implementation. Classes define types with implementations. Execution of
a Sather program begins with a routine named `main' in a specified
class (*note main::).


File: sather.info,  Node: Abstract type definitions,  Next: Classes,  Prev: Sather source files,  Up: Types and Classes

Abstract type definitions
=========================

Example:

     type $SHIPPING_CRATE{T} < $CONTAINER{T} is
        destination:$LOCATION;
        weight:FLT;
     end

Syntax:

     ABSTRACT_TYPE_DEFINITION => `type' ABSTRACT_TYPE_NAME
        [ { PARAMETER_DECLARATION { , PARAMETER_DECLARATION } } ]
        [ SUBTYPING_CLAUSE ] [ SUPERTYPING_CLAUSE ]
        `is' [ ABSTRACT_SIGNATURE ] { ; [ ABSTRACT_SIGNATURE ] } `end'
     
     PARAMETER_DECLARATION => UPPERCASE_IDENTIFIER [ < TYPE_SPECIFIER]
     
     SUBTYPING_CLAUSE => < TYPE_SPECIFIER_LIST
     
     SUPERTYPING_CLAUSE => > TYPE_SPECIFIER_LIST
     
     TYPE_SPECIFIER_LIST => TYPE_SPECIFIER { , TYPE_SPECIFIER}
     
     ABSTRACT_SIGNATURE => ( IDENTIFIER | ITER_NAME)
        [ (ABSTRACT_ARGUMENT { , ABSTRACT_ARGUMENT } ) ] [ : TYPE_SPECIFIER ]
     
     ABSTRACT_ARGUMENT => IDENTIFIER_LIST : TYPE_SPECIFIER [ ! ]

Abstract type definitions specify interfaces without implementations.
Abstract type names must be entirely uppercase and must begin with a
dollar sign "$" (*note Lexical Structure::).

Abstract type definitions may be _parameterized_ by one or more type
parameters within enclosing braces. The scope of abstract type names is
the entire program. Two abstract type definitions may define types with
the same name only if they specify a different number of type
parameters. Type parameter names are local to the abstract type
definition and they shadow non-parameterized types with the same name.
Parameter names must be all uppercase, and they may be used within the
abstract type definition as type specifiers. Whenever a parameterized
type is referred to, its parameters are specified by type specifiers.
The abstract type definition behaves like a non-parameterized version
whose body is a textual copy of the original definition in which each
parameter occurrence is replaced by its specified type.

If a parameter declaration is followed by a type constraint clause (`<'
followed by a type specifier), then the parameter can only be replaced
by subtypes of the constraining type. If a type constraint is not
explicitly specified, then `< $OB' is taken as the constraint. An
abstract type definition must satisfy all of the typing rules when its
parameters are replaced by any subtype of their constraining types.

A subtyping clause adds to the type graph an edge from each type in the
TYPE_SPECIFIER_LIST to the type being defined. Each listed type must be
abstract. Every type is automatically a subtype of $OB (*note Built-in
Classes::). There must be no cycle of abstract types such that each
appears in the subtype list of the next, ignoring the values of any
type parameters but not their number.

A supertyping clause adds to the type graph an edge from the type being
defined to each type in the TYPE_SPECIFIER_LIST. These type specifiers
may not be type parameters (though they may include type parameters as
components) or external types. There must be no cycle of abstract
classes such that each class appears in the supertype list of the next,
ignoring the values of any type parameters but not their number. If
both subtyping and supertyping clauses are present, then each type in
the supertyping list must be a subtype of each type in the subtyping
list using only edges introduced by subtyping clauses. This ensures
that the subtype relationship can be tested by examining only
definitions reachable from the two types in question.

The body of abstract type definitions consists of a semi-colon separated
list of abstract signatures. Each specifies the signature of a routine
or iter without providing an implementation. The argument names are for
documentation purposes only and do not affect the semantics. The
ABSTRACT_SIGNATURES of all types listed in the subtyping clause are
included in the interface of the type being defined. Explicitly
specified signatures override any conflicting signatures from the
subtyping clause. If two types in the subtyping clause have conflicting
signatures that are not equal, then the type definition must explicitly
specify a signature that overrides them. The interface of an abstract
type consists of any explicitly specified signatures along with those
introduced by the subtyping clause.


File: sather.info,  Node: Classes,  Next: Type specifiers,  Prev: Abstract type definitions,  Up: Types and Classes

Classes
=======

Examples:

     class VIEWER{DATA < $VIEWER_DATA} is ... end
     value class DOLPHIN < $MAMMAL, $SWIMMER is ... end
     external class `EXT' is ... end

Syntax:

     CLASS => [ value | external ] class UPPERCASE_IDENTIFIER
        [ { PARAMETER_DECLARATION { , PARAMETER_DECLARATION } } ]
        [ SUBTYPING_CLAUSE ]
        is [ CLASS_ELEMENT ] { ; [ CLASS_ELEMENT ] } end

Classes define the types that have implementations: reference, value,
and external types are defined by classes beginning with `class',
`value class', and `external class', respectively. Class names must be
entirely uppercase (*note Lexical Structure::). Reference and value
classes may be _parameterized_ by one or more type parameters. The
scope of class names is the entire program and two classes may have the
same name only if they specify a different number of type parameters.

Class types may optionally declare one or more _type parameters_ within
enclosing braces.  Type parameter names are local to the class
definition in which they appear and they shadow non-parameterized types
with the same name. Parameter names must be all uppercase, and they may
be used within the class body as type specifiers. Whenever a
parameterized type is referred to, its parameters are specified by type
specifiers. The class behaves like a non-parameterized version whose
body is a textual copy of the original class in which each parameter
occurrence is replaced by its specified type.

If a parameter declaration is followed by a type constraint clause (`<'
followed by a type specifier), then the parameter can only be replaced
by subtypes of the constraining type. If a type constraint is not
explicitly specified, then `< $OB' is taken as the constraint. A type
constraint specifier may not refer to `SAME'. The body of a
parameterized class must be type-correct when the parameters are
replaced by any subtype of their constraining types.

Subtyping clauses introduce edges into  the type graph. The
type_specifier_list must consist of only abstract types. There is an
edge in the type graph from each type in the list to the type being
defined. Every type is automatically a subtype of `$OB' (*note Built-in
Classes::).


File: sather.info,  Node: Type specifiers,  Prev: Classes,  Up: Types and Classes

Type specifiers
===============

Examples:

     A{B,C{$D}}
     ROUT{A,B,C}:D
     ITER{A,B!,C}
     SAME

Syntax:

     TYPE_SPECIFIER => ( UPPERCASE_IDENTIFIER | ABSTRACT_TYPE_NAME )
        [ { TYPE_SPECIFIER_LIST } ]
        | ( ROUT | ITER )
           [ { TYPE_SPECIFIER [ ! ] { , TYPE_SPECIFIER [ ! ] } } ]
           [ : TYPE_SPECIFIER ]
        | SAME

In source text, Sather types are specified by one of the following forms
of _type specifier_:

   * The name of a non-parameterized class or abstract type (e.g. `A' or
     `$A').

   * The name of a parameterized class or abstract type followed by a
     list of parameter type specifiers in braces (e.g. `A{B,C}'). The
     parameter values must not cause the generation of an infinite
     number of types (e.g.  `FOO{FOO{T}}' within the class `FOO{T}').

   * The name of a type parameter within the body of a parameterized
     class or abstract type definition (e.g. `T' in the body of `class
     B{T} is ... end').

   * The keyword `ROUT' or `ITER' optionally followed by a list of
     argument types in braces, optionally followed by a colon and
     return type (e.g. `ROUT{A,B}:C'). Bound iter argument types may be
     followed by a "!"  (*note Bound routine and iter creation
     expressions::, e.g. `ITER{A!}:D').

   * The special type specifier `SAME', which denotes the type of the
     class in which it appears. It may not appear in abstract type
     definitions.


File: sather.info,  Node: Class Elements,  Next: Statements,  Prev: Types and Classes,  Up: Top

Class Elements
**************

Syntax:

     CLASS_ELEMENT => CONST_DEFINITION | SHARED_DEFINITION | ATTR_DEFINITION |
        ROUTINE_DEFINITION | ITER_DEFINITION | INCLUDE_CLAUSE

The main body of each class is a semicolon separated list of _feature_
definitions and `include' clauses. The possible features of a class
are: _constant attributes_, _shared attributes_, _object attributes_,
_routines_ and _iters_. The semantics of a class is independent of the
textual order of the class elements. All features are named and
attributes may contribute a reader and a writer routine of the same
name to the class interface. The scope of feature names is the class
body and is separate from the class namespace. If a feature is
_private_, then it may only be referred to from within the class and is
not part of the class interface.

* Menu:

* Constant attribute definitions::
* Shared attribute definitions::
* Object attribute definitions::
* Routine definitions::
* Iter definitions::
* include clauses::


File: sather.info,  Node: Constant attribute definitions,  Next: Shared attribute definitions,  Prev: Class Elements,  Up: Class Elements

Constant attribute definitions
==============================

Examples:

     const r:FLT:=45.6
     private const a,b,c

Syntax:

     CONST_DEFINITION => [ private ] const IDENTIFIER
        ( : TYPE_SPECIFIER := EXPRESSION | [ := EXPRESSION ] [ , IDENTIFIER_LIST ] )
        IDENTIFIER_LIST => IDENTIFIER { , IDENTIFIER }

Constant attributes are accessible by all objects in a class and may not
be assigned to. If a type is specified, then the construct defines a
single constant attribute named IDENTIFIER and it must be initialized
by the expression EXPRESSION. This must be a constant expression which
means that it is:

  1. a character, boolean, character, string, integer or floating point
     literal expression (*note Boolean literal expressions::),

  2. a `void' or `void' test expression (*note void expressions::),

  3. an `and' or `or' expression (*note and expressions::), each of
     whose components is a constant expression,

  4. an array creation expression (*note Array creation expressions::),
     each of whose components is a constant expression,

  5. a routine call applied to a constant expression, each of whose
     arguments is a constant expression (*note Routine and iter call
     expressions::),

  6. or a reference to another constant in the same class or in another
     class using the `::' notation (*note Routine and iter call
     expressions::).

There must not be cyclic dependencies among constant initializers.

If a type specifier is not provided, then the construct defines one or
more successive integer constants. The first identifier is assigned the
value zero by default or its value may be specified by an integer
expression. The remaining identifiers are assigned successive integer
values.

Each constant attribute definition causes the definition of a reader
routine with the same name. It takes no arguments and returns the value
of the constant. Its return type is the constant's type. The routine is
private if and only if the constant is declared `private'.


File: sather.info,  Node: Shared attribute definitions,  Next: Object attribute definitions,  Prev: Constant attribute definitions,  Up: Class Elements

Shared attribute definitions
============================

Examples:

     private shared i,j:INT
     shared s:STR:="name"
     readonly shared c:CHAR:='x'

Syntax:

     SHARED_DEFINITION => [ private | readonly ] shared
        ( IDENTIFIER : TYPE_SPECIFIER := EXPRESSION | IDENTIFIER_LIST : TYPE_SPECIFIER )

_Shared attributes_ are variables that are directly accessible to all
objects of a given type. When only a single shared attribute is defined
by a clause, it may be provided with an initializing expression which
must be a constant expression (*note Constant attribute definitions::).
If no initializing expression is provided, the shared is initialized
the same as object attributes of that type would be (*note Object
attribute definitions::).

Each shared attribute definition causes the definition of a reader and
a writer routine with the same name. The reader routine takes no
arguments and returns the value of the shared.  Its return type is the
shared's type. The reader routine  is private if and only if the shared
is declared `private'. The writer routine sets the value of the shared,
taking a single argument whose type is the shared's type, and has no
return value. The writer routine  is private if and only if the shared
is declared either `private' or `readonly'.


File: sather.info,  Node: Object attribute definitions,  Next: Routine definitions,  Prev: Shared attribute definitions,  Up: Class Elements

Object attribute definitions
============================

Examples:

     attr a,b,c:INT
     private attr c:CHAR
     readonly attr s1,s2:STR

Syntax:

     ATTR_DEFINITION [ private | readonly ] attr IDENTIFIER_LIST : TYPE_SPECIFIER

An object's state consists of the _object attributes_ defined in its
class together with an optional array portion. The array portion
appears if there is an `include' path (*note include clauses::) from
the type to `AREF' for reference types or to `AVAL' for value types
(*note Built-in Classes::). Bound and reference objects must be
explicitly allocated as described in *Note new expressions::, and *Note
Bound routine and iter creation expressions::. Variables have the value
`void' until an object is assigned to them (*note void expressions::).
There must be no cycle of value types where each type has an object
attribute whose type is the next in the cycle.  External classes may
not define object attributes.

Each object attribute definition causes the definition of a reader and
a writer routine with the same name. The reader routine takes no
arguments and returns the value of the attribute. Its declared return
type is the attribute's type. It is private if and only if the
attribute is declared `private'.

The writer routine takes different forms for reference and value types.
For reference types, it takes a single argument whose type is the
attribute's type and has no return value. Its effect is to modify the
object by setting the value of the attribute. For value types, it takes
a single argument whose type is the attribute's type, and returns a
copy of the object with the attribute set to the specified new value,
and whose type is the type of the object. This difference arises
because it is not possible to modify value objects once they are
constructed.  Object attribute writer routines are private if and only
if the corresponding attribute is declared either `private' or
`readonly'.


File: sather.info,  Node: Routine definitions,  Next: Iter definitions,  Prev: Object attribute definitions,  Up: Class Elements

Routine definitions
===================

Examples:

     a(f:FLT):FLT pre f>1.2 post result<4.3 is ... end
     b is ... end
     private d:INT is ... end
     c(s1,s2,s3:STR)

Syntax:

     ROUTINE_DEFINITION => [ private ] IDENTIFIER
        [ ( ROUTINE_ARGUMENT { , ROUTINE_ARGUMENT } ) ]
        [ : TYPE_SPECIFIER ]
        [ pre EXPRESSION ] [ post EXPRESSION ]
        [ is STATEMENT_LIST end ]
     
     ROUTINE_ARGUMENT => IDENTIFIER_LIST : TYPE_SPECIFIER

A _routine_ definition may begin with the keyword `private' to indicate
that the routine may be called from within the class but is not part of
the class interface. The IDENTIFIER specifies the name of the routine.

If a routine has arguments, the declaration list is enclosed in
parentheses. The name and type of each argument is specified in this
list. The types of consecutive arguments may be declared with a single
type specifier. If a routine has a return value, it is declared by a
colon and a specifier for the return type.

The optional `pre' construct contains a boolean expression which must
evaluate to `true' whenever the routine is called; it is a fatal error
if it evaluates to `false'. The expression may refer to `self' and to
the routine's arguments.

The optional `post' construct contains a boolean expression which must
evaluate to `true' whenever the routine returns; it is a fatal error if
it evaluates to `false'. The expression may refer to `self' and to the
routine's arguments. It may use `result' expressions (*note result
expressions::) to refer to the value returned by the routine and
`initial' expressions (*note initial expressions::) to refer to values
which are computed before the routine executes.

The body of a routine definition is a list of statements (*note
Statements::). The body is optional in external classes (*note
Interfacing with other Languages::).


File: sather.info,  Node: Iter definitions,  Next: include clauses,  Prev: Routine definitions,  Up: Class Elements

Iter definitions
================

Example:

     elts!(i:INT, x:FLT!):T is ... end

Syntax:

     ITER_DEFINITION => [ private ] ITER_NAME
        [ ( ITER_ARGUMENT { , ITER_ARGUMENT } ) ]
        [ : TYPE_SPECIFIER ]
        [ pre EXPRESSION ] [ post EXPRESSION ] is STATEMENT_LIST end
     
     ITER_ARGUMENT => IDENTIFIER_LIST : TYPE_SPECIFIER [ ! ]

_Iters_ are similar to routines but encapsulate iteration abstractions.
Their names end with an exclamation point "!" and they may only be
called within `loop' statements (*note loop statements::). Iter
argument type specifiers may be followed by a "!"  to cause
re-evaluation of that argument at each iteration.

The description of routine arguments and `pre' and `post' constructs
also applies to iter definitions. Iters may contain `yield' (*note
yield statements::) and `quit' (*note quit statements::) statements but
may not contain `return' statements. The semantics of iter calls is
described in the section on loop statements (*note loop statements::) .
The `pre' clause must be true each time the iter is called and the
`post' clause must be true each time it yields. The `post' clause is
not evaluated when an iter quits.


File: sather.info,  Node: include clauses,  Prev: Iter definitions,  Up: Class Elements

`include' clauses
=================

Examples:

     include A a->b, c->, d->private d;
     private include D e->readonly f;

Syntax:

     INCLUDE_CLAUSE => [ private ] include TYPE_SPECIFIER
        [ FEATURE_MODIFIER { , FEATURE_MODIFIER } ]
     
     FEATURE_MODIFIER => ( IDENTIFIER | ITER_NAME ) ->
        [ [ private | readonly ] ( IDENTIFIER | ITER_NAME ) ]

Implementation inheritance is defined by _include clauses_. These cause
the incorporation of the implementation of the specified type, possibly
undefining or renaming features with FEATURE_MODIFIER clauses. External
classes may not have include clauses. The `include' clause may begin
with the keyword `private', in which case any unmodified included
feature is made private. We say that there is an _include path_ from
one type to another if there is a sequence of types between them such
that each includes the next in the sequence.

The included type specified by the TYPE_SPECIFIER must not be an
external type, a bound type, or a type parameter (though type parameters
may appear as components of the type specifier). There mustn't be
include paths from reference types to `AVAL' or from value types to
`AREF' (*note Built-in Classes::). There must be no cycle of classes
such that each class includes the next, ignoring the values of any type
parameters but not their number.

Each FEATURE_MODIFIER clause specifies an identifier which must be the
name of at least one feature in the included class. If no clause
follows the `->' symbol, then the named features are not included in
the class. If an identifier follows the `->' symbol, then it becomes
the new name for the features. In this case, the listed features are
included as part of the public interface unless they are specified as
`private' or `readonly'. Identifiers may only be renamed as identifiers
and iter names may only be renamed by iter names.

A class may not explicitly define two routines or iters whose signatures
conflict (*note Types and Classes::). A class may not define a routine
whose signature conflicts with either the reader or the writer routine
of any of its attributes (whether explicitly defined or included from
other classes).  If a routine or iter is explicitly defined in a class,
it overrides all conflicting routines or iters from included classes.
The reader and writer routines of a class's attributes also override
any included routines and must not conflict with each other. If an
included routine or iter is not overridden, then it must not conflict
with another included routine or iter. Feature modification clauses can
be used to resolve any conflicts.


File: sather.info,  Node: Statements,  Next: Expressions,  Prev: Class Elements,  Up: Top

Statements
**********

Syntax:

     STATEMENT_LIST => [ STATEMENT ] { ; [ STATEMENT ] }
     
     STATEMENT => DECLARATION_STATEMENT | ASSIGN_STATEMENT
        | IF_STATEMENT | LOOP_STATEMENT | RETURN_STATEMENT
        | YIELD_STATEMENT | QUIT_STATEMENT | CASE_STATEMENT
        | TYPECASE_STATEMENT | ASSERT_STATEMENT | PROTECT_STATEMENT
        | RAISE_STATEMENT | EXPRESSION_STATEMENT

The body of a routine or iter is a semicolon separated list of
statements. The statements in a statement list are executed sequentially
unless a `return', `quit', `yield', or `raise' statement is executed.
In a routine with a return value, the final statement along each
execution path must be either a `return' statement or a `raise'
statement.

* Menu:

* Declaration statements::
* Assignment statements::
* if statements::
* loop statements::
* yield statements::
* quit statements::
* return statements::
* case statements::
* typecase statements::
* assert statements::
* protect statements::
* raise statements::
* Expression statements::


File: sather.info,  Node: Declaration statements,  Next: Assignment statements,  Prev: Statements,  Up: Statements

Declaration statements
======================

Example:

     i,j,k:INT

Syntax:

     DECLARATION_STATEMENT => IDENTIFIER_LIST : TYPE_SPECIFIER

_Declaration statements_ are used to declare the type of one or more
local variables. Local variables may also be declared in assignment
statements (*note Assignment statements::). The scope of a local
variable declaration begins at the declaration and continues to the end
of the statement list in which the declaration occurs. The scope of
routine and iter arguments is the entire body of the routine or iter.
Local variables shadow routines in the class which have the same name
and no arguments. Within the scope of a local variable it is illegal to
declare another local variable with the same name. Local variables are
initialized to `void' (*note void expressions::) when the containing
routine or iter is called.


File: sather.info,  Node: Assignment statements,  Next: if statements,  Prev: Declaration statements,  Up: Statements

Assignment statements
=====================

Examples:

     a:=5
     b(7).c:=5
     A::d:=5
     [3]:=5
     e[7,8]:=5
     g:INT:=5
     h::=5

Syntax:

     ASSIGN_STATEMENT ( EXPRESSION | IDENTIFIER : [ TYPE_SPECIFIER ] ) := EXPRESSION

_Assignment statements_ are used to assign objects to locations and can
also declare new local variables. The expression on the right-hand side
must have a return type which is a subtype of the declared type of the
destination specified by the left hand side. When a reference object is
assigned to a location, only a REFERENCE to the object is assigned.
This means that later changes to the state of the object will be
observable from the assigned location. Since value and bound objects
cannot be modified once constructed, this issue is not relevant to them.
We consider each of the allowed forms for the left-hand side of an
assignment in turn:

  1. "IDENTIFIER"

     If the left hand side is a local variable or an argument of a
     routine or iter, then the assignment is directly performed (e.g.
     `a:=5').  Otherwise the statement is syntactic sugar for a call of
     the routine named IDENTIFIER with the right hand side of the
     assignment as the only argument (e.g. `a(5)').

  2. "( EXPRESSION . | TYPE_SPECIFIER :: ) IDENTIFIER"

     These forms are syntactic sugar for calls of a routine named
     identifier with the right-hand side as an argument: ( EXPRESSION .
     | TYPE_SPECIFIER :: ) IDENTIFIER ( RHS ). For example, `b(7).c:=5'
     is sugar for `b(7).c(5)' and `A::d:=5' is sugar for `A::d(5)'.

  3. "[ EXPRESSION ] [ EXPRESSION_LIST ] "

     This form is syntactic sugar for a call on a routine named `aset'
     with the array index expressions and the right-hand side of the
     assignment as arguments: [ EXPRESSION . | TYPE_SPECIFIER :: ] ASET(
     EXPRESSION_LIST , RHS ). For example, `[3]:=5' is sugar for
     `aset(3,5)' and `e[7,8]:=5' is sugar for `e.aset(7,8,5)'.

  4. "IDENTIFIER : [ TYPE_SPECIFIER ]"

     This form both declares a new local variable and assigns to it
     (e.g. `g:INT:=5'). If a type specifier is not provided, then the
     declared type of the variable is the return type of the expression
     on the right-hand side (e.g. `h::=5'). The scoping rules given in
     *Note Declaration statements::, apply here as well. If a type is
     explicitly specified, the construct is syntactic sugar for a
     declaration statement followed by an assignment statement.


File: sather.info,  Node: if statements,  Next: loop statements,  Prev: Assignment statements,  Up: Statements

`if' statements
===============

Example:

     if a>5 then foo elsif a>2 then bar else error end

Syntax:

     IF_STATEMENT => if EXPRESSION then STATEMENT_LIST
        { elsif EXPRESSION then STATEMENT_LIST }
        [ else STATEMENT_LIST ] end

_if statements_ are used to conditionally execute statement lists
according to the value of a boolean expression. Each EXPRESSION in the
form must return a boolean value. The first expression is evaluated and
if it is true, the following statement list is executed. If it is
false, then the expressions of successive `elsif' clauses are evaluated
in order. The statement list following the first of these to return
`true' is executed. If none of the expressions return `true' and there
is an `else' clause, then its statement list is executed.


File: sather.info,  Node: loop statements,  Next: yield statements,  Prev: if statements,  Up: Statements

`loop' statements
=================

Example:

     loop ... end

Syntax:

     LOOP_STATEMENT => loop STATEMENT_LIST end

Iteration is done with _loop statements_, used in conjunction with iter
calls (*note Routine and iter call expressions::). An execution state
is maintained for each textual iter call. When a loop is entered, the
execution state of all enclosed iter calls is initialized. When an iter
is first called in a loop, the expressions for `self' and for each
argument without a "!"  marking are evaluated left to right. Then the
expressions for "!"  arguments are evaluated left to right. On
subsequent calls, only the expressions for "!" arguments are
re-evaluated. `self' and any arguments not marked with a "!"  retain
their earlier values. The expressions for `self' and for arguments not
marked "!" in an iter call may not themselves contain iter calls (such
iters would only execute their first iteration).

When an iter is called, it executes the statements in its body in
order. If it executes a `yield' statement, control is returned to the
caller. Subsequent calls on the iter resume execution with the
statement following the `yield' statement. If an iter executes `quit'
or reaches the end of its body, control passes immediately to the end
of the innermost enclosing loop statement in the caller and no value is
returned from the iter.


File: sather.info,  Node: yield statements,  Next: quit statements,  Prev: loop statements,  Up: Statements

`yield' statements
==================

Examples:

     yield
     yield x

Syntax:

     YIELD_STATEMENT => yield [ EXPRESSION ]

_yield statements_ are used to return control to a loop and may appear
only in iter definitions.  The EXPRESSION clause must be present if the
iter has a return value and must be absent if it does not. If
EXPRESSION is present, then its type must be a subtype of the return
type. Execution of a `yield' statement causes the expression to be
evaluated and its value to be returned to the caller of the iter in
which it appears.


File: sather.info,  Node: quit statements,  Next: return statements,  Prev: yield statements,  Up: Statements

`quit' statements
=================

Example:

     quit

Syntax:

     QUIT_STATEMENT => quit

_quit statements_ are used to terminate loops and may only appear in
iter definitions. No value is returned from an iter when it quits. No
statements may follow a `quit' statement in a statement list.


File: sather.info,  Node: return statements,  Next: case statements,  Prev: quit statements,  Up: Statements

`return' statements
===================

Examples:

     return
     return x

Syntax:

     RETURN_STATEMENT => return [ EXPRESSION ]

_return statements_ are used to return from routine calls. No other
statements may follow a `return' statement in a statement list because
they could never be executed. If a routine doesn't have a return value
then it may return either by executing a `return' statement without an
EXPRESSION portion or by executing the last statement in the routine
body.

If a routine has a return value, then its `return' statements must
specify expressions whose types are subtypes of the routine's declared
return type. Execution of the `return' statement causes the expression
to be evaluated and its value to be returned. It is a fatal error if
the final statement executed in such a routine is not a `return'
statement.


File: sather.info,  Node: case statements,  Next: typecase statements,  Prev: return statements,  Up: Statements

`case' statements
=================

Example:

     case i
        when 5, 6 then ...
        when j then ...
        else ... end

Syntax:

     CASE_STATEMENT => case EXPRESSION
        { when EXPRESSION { , EXPRESSION } then STATEMENT_LIST }
        [ else STATEMENT_LIST ] end

Multi-way branches are implemented by _case statements_. There may be
an arbitrary number of _when clauses_ and an optional _else clause_.
The initial EXPRESSION construct is evaluated first and may have a
return value of any type. This type must define one or more routines
named `is_eq' with a single argument and a boolean return value. The
case statement is semantically syntactic sugar for (equivalent to) an
`if' statement, each of whose branches tests a call of `is_eq'. The
arguments to these calls are the successive expressions of successive
`when' lists. If one of these calls returns `true', then the
corresponding statement list is executed and control passes to the
statement following the `case' statement. If none of the `when'
expressions matches and an `else' clause is present, then the statement
list following it is executed. It is a fatal error if no branch matches
in the absence of an `else' clause.


File: sather.info,  Node: typecase statements,  Next: assert statements,  Prev: case statements,  Up: Statements

`typecase' statements
=====================

Example:

     typecase a
        when INT then ...
        when FLT then ...
        when $A then ...
        else ... end

Syntax:

     TYPECASE_STATEMENT => typecase IDENTIFIER
        { when TYPE_SPECIFIER then STATEMENT_LIST }
        [ else STATEMENT_LIST ] end

An operation that depends on the runtime type of an object held by a
variable of abstract type may be performed inside a _typecase
statement_. The IDENTIFIER must name a local variable or an argument of
a routine or iter. If the `typecase' appears in an iter, then the
IDENTIFIER must not refer to a "!" argument, because the type of object
that such an argument holds could change.

On execution, each successive TYPE_SPECIFIER is tested for being a
supertype of the type of the object held by the variable. The statement
list following the first matching type specifier is executed and control
passes to the statement following the `typecase'. Within that statement
list, the type of the `typecase' variable is taken to be the type
specified by the matching type specifier unless the variable's declared
type is a subtype of it, in which case it retains its declared type. It
is not legal to assign to the `typecase' variable within the statement
lists. If the object's type is not a subtype of any of the type
specifiers and an `else' clause is present, then the statement list
following it is executed. It is a fatal error for no branch to match in
the absence of an `else' clause. The declared type of the variable is
not changed within the `else' statement list. If the value of the
variable is `void' when the `typecase' is executed, then its type is
taken to be the declared type of the variable.


File: sather.info,  Node: assert statements,  Next: protect statements,  Prev: typecase statements,  Up: Statements

`assert' statements
===================

Example:

     assert x>5

Syntax:

     ASSERT_STATEMENT => assert EXPRESSION

_assert statements_ specify a boolean expression that must evaluate to
`true'; otherwise it is a fatal error.


File: sather.info,  Node: protect statements,  Next: raise statements,  Prev: assert statements,  Up: Statements

`protect' statements
====================

Example:

     protect ...
        when E then ...
        when $F then ...
        else ... end

Syntax:

     PROTECT_STATEMENT => protect STATEMENT_LIST
        { when TYPE_SPECIFIER then STATEMENT_LIST }
        [ else STATEMENT_LIST ] end

Sather uses _exceptions_ to signal and recover from exceptional
situations. Exceptions may be explicitly raised by a program (*note
raise statements::) or generated by the system. Each exception is
represented by an _exception object_ whose type is used to select a
handler from a _protect statement_. Execution of a `protect' statement
begins with the statement list following the `protect' keyword. If all
exceptions which are raised are handled by other `protect' statements,
then the statements in this list are executed to completion.

If an exception is raised which is not handled elsewhere, then the
system finds the first type specifier listed in the `when' lists which
is a supertype of the exception object type. The statement list
following this specifier is executed and then control passes to the
statement following the `protect' statement. An `exception' expression
(*note exception expressions::) may be used to access the exception
object in these handler statements. If none of the specified types are
supertypes, then the statements in an `else' clause are executed if it
is present. If it is not present, the same exception object is raised
to the next most recently entered `protect' statement which is still in
progress. It is a fatal error to raise an exception which is not
handled by some `protect' statement. `protect' statements may only
contain iter calls if they also contain the surrounding loop.


File: sather.info,  Node: raise statements,  Next: Expression statements,  Prev: protect statements,  Up: Statements

`raise' statements
==================

Example:

     raise x

Syntax:

     RAISE_STATEMENT => raise EXPRESSION

Exceptions are explicitly raised by _raise statements_. The EXPRESSION
is evaluated to obtain the exception object. No statements may follow a
`raise' statement in a statement list because they could never be
executed.


File: sather.info,  Node: Expression statements,  Prev: raise statements,  Up: Statements

Expression statements
=====================

Example:

     foo(1,2)

Syntax:

     EXPRESSION_STATEMENT => EXPRESSION

A statement may consist of an expression (*note Expressions::) which
doesn't return a value and is executed solely for its side-effects.


File: sather.info,  Node: Expressions,  Next: Lexical Structure,  Prev: Statements,  Up: Top

Expressions
***********

Syntax:

     EXPRESSION => SELF_EXPRESSION | LOCAL_EXPRESSION | CALL_EXPRESSION
        | VOID_EXPRESSION | VOID_TEST_EXPRESSION | NEW_EXPRESSION
        | CREATE_EXPRESSION | ARRAY_EXPRESSION | BOUND_CREATE_EXPRESSION
        | SUGAR_EXPRESSION | AND_EXPRESSION | OR_EXPRESSION | EXCEPT_EXPRESSION
        | INITIAL_EXPRESSION | RESULT_EXPRESSION | WHILE!_EXPRESSION
        | UNTIL!_EXPRESSION | BREAK!_EXPRESSION | BOOL_LITERAL_EXPRESSION
        | CHAR_LITERAL_EXPRESSION | STR_LITERAL_EXPRESSION
        | INT_LITERAL_EXPRESSION | FLT_LITERAL_EXPRESSION

Sather _expressions_ are used to compute values or to cause
side-effects.  If they return a value, then they have a _return type_
that is either explicitly declared or inferred from context.

* Menu:

* self expressions::
* Local variable access expressions::
* Routine and iter call expressions::
* void expressions::
* void test expressions::
* new expressions::
* Creation expressions::
* Array creation expressions::
* Bound routine and iter creation expressions::
* Syntactic sugar expressions::
* and expressions::
* or expressions::
* exception expressions::
* initial expressions::
* result expressions::
* while! expressions::
* until! expressions::
* break! expressions::


File: sather.info,  Node: self expressions,  Next: Local variable access expressions,  Prev: Expressions,  Up: Expressions

`self' expressions
==================

Example:

     self

Syntax:

     SELF_EXPRESSION => self

_self expressions_ may appear in the bodies and in the `pre' and `post'
clauses of routines and iters. They return the object on which the
routine or iter was called. The return type is the type in which the
routine or iter appears.


File: sather.info,  Node: Local variable access expressions,  Next: Routine and iter call expressions,  Prev: self expressions,  Up: Expressions

Local variable access expressions
=================================

Example:

     a

Syntax:

     LOCAL_EXPRESSION => IDENTIFIER

The name of an argument or local variable in a routine or iter is an
expression which returns the value of that variable. The return type of
such an expression is the declared type of the variable. Local variables
may be accessed only within the body of a routine or iter.  Arguments
may additionally be accessed in routine and iter `pre' and `post'
clauses.

All other expressions consisting of a single identifier are routine or
iter calls on `self' as described in the next section.


File: sather.info,  Node: Routine and iter call expressions,  Next: void expressions,  Prev: Local variable access expressions,  Up: Expressions

Routine and iter call expressions
=================================

Examples:

     a(5,7)
     b.a(5,7)
     A::a(5,7)

Syntax:

     CALL_EXPRESSION => [ EXPRESSION . | TYPE_SPECIFIER :: ]
        ( IDENTIFIER | ITER_NAME ) [ ( EXPRESSION_LIST ) ]
     
     EXPRESSION_LIST => EXPRESSION { , EXPRESSION }

The most common expressions in Sather programs are _routine and iter
calls_. The IDENTIFIER names the routine or iter being called. The
object to which the routine or iter is applied is determined by what
precedes the IDENTIFIER. If nothing precedes it, then the form is
syntactic sugar for a call on `self' (e.g. `a(5,7)' is short for
`self.a(5,7)'). If the IDENTIFIER is preceded by an expression and a
dot `.', then the routine or iter is called on the object returned by
the expression. If IDENTIFIER is preceded by a type specifier and a
double colon `::', then the routine or iter is taken from the interface
of the specified type with `self' initialized as described in *Note
Object attribute definitions::.

Routine calls are evaluated by first evaluating the expression to the
left of the dot, if present, then evaluating any argument expressions
from left to right and then calling the routine. The evaluation of iter
calls is described in *Note loop statements::.

Sather supports routine and iter _overloading_. In addition to the
name, the number and types of arguments in a call and whether a return
value is used contribute to the selection of the routine or iter. The
EXPRESSION_LIST portion of a call must supply an expression
corresponding to each declared argument of the routine or iter. There
must be a routine or iter with the specified name such that the type of
each expression is a subtype of the declared type of the corresponding
argument and it must be unique. If the routine or iter defines a return
value, it must be used (i.e. the call may not be an
EXPRESSION_STATEMENT). Only non-private routines and iters may be
called from outside a class, but all routines and iters may be called
from inside a class.

Sather also supports _dynamic dispatch_ on the type of `self' when the
expression on which the call is made has an abstract declared return
type. The routine or iter matching the call from the runtime type of
the returned object is actually executed. Because of the subtyping rule
(*note Types and Classes::), if the abstract type specifies a
conforming routine or iter, so will the type of the returned object.

Direct calls of a type's routines or iters may be made using the double
colon `::' syntax.  The TYPE_SPECIFIER must specify a reference, value,
or external class. In such calls `self' has the default value described
in *Note Object attribute definitions::.


File: sather.info,  Node: void expressions,  Next: void test expressions,  Prev: Routine and iter call expressions,  Up: Expressions

`void' expressions
==================

Example:

     void

Syntax:

     VOID_EXPRESSION => VOID

A _void expression_ returns a value whose type is determined from
context. `void' is the value that a variable of the type receives when
it is declared but not explicitly initialized. The value of `void' for
abstract, reference, and bound variables is a special value that
represents the absence of a reference to an object. The value of `void'
for boolean variables is `false' (*note Boolean literal expressions::)
and for other value types it is determined by recursively setting each
attribute and array element to `void'. The built-in value types are
defined in terms of arrays of `BOOL' and so have all their bits set to
0 by this rule.

`void' expressions may appear as the initializer for a constant or
shared attribute, as the right hand side of an assignment statement, as
the return value in a `return' or `yield' statement, as the value of
one of the expressions in a `case' statement, as the exception object
in a `raise' statement, or as an argument value in a routine or iter
call or in a creation expression (*note Creation expressions::). In
this last case, the argument is ignored in resolving overloading.

It is a fatal error to access object attributes of a void variable of
reference type or to make any calls on a void variable of abstract
type. It is not legal to dot into an explicit `void' expression.


File: sather.info,  Node: void test expressions,  Next: new expressions,  Prev: void expressions,  Up: Expressions

`void' test expressions
=======================

Example:

     void(a)

Syntax:

     VOID_TEST_EXPRESSION => void ( EXPRESSION )

_Void test expressions_ evaluate their argument and return a boolean
value which is true if the value is `void' (*note void expressions::).


File: sather.info,  Node: new expressions,  Next: Creation expressions,  Prev: void test expressions,  Up: Expressions

`new' expressions
=================

Examples:

     new
     new(17)

Syntax:

     NEW_EXPRESSION => new [ ( EXPRESSION ) ]

_new expressions_ are used to allocate space for reference objects and
may only appear in reference classes. They return reference objects of
type `SAME'. All attributes and array elements are initialized to
`void' (*note void expressions::). If there is an `include' path from
the type in which the `new' appears to `AREF' (*note Built-in
Classes::), then `new' must be provided with a non-negative `INT'
argument which specifies the number of array elements in the returned
object.


File: sather.info,  Node: Creation expressions,  Next: Array creation expressions,  Prev: new expressions,  Up: Expressions

Creation expressions
====================

Examples:

     #FOO(1,2,3)
     #(1,2,3)
     #FOO
     #

Syntax:

     CREATE_EXPRESSION => # [ TYPE_SPECIFIER ] [ ( EXPRESSION_LIST ) ]

Value and reference object _creation expressions_ are a convenient
shorthand used for creating new objects and initializing their
attributes. A creation expression is syntactic sugar for a call on a
routine named `create' with the specified arguments. `self' is given
the default value described in *Note Object attribute definitions::, in
this call. The type defining the `create' routine may be explicitly
specified as a reference or value type. If the type is not explicitly
specified, then it is taken to be the declared type of the context in
which the call appears (and it must be a value or reference type). A
type must be specified if the expression appears as the right-hand side
of a `::=' assignment (*note Assignment statements::), as a routine or
iter argument in which overloading resolution would otherwise be
ambiguous, or as the object on which a call is made.


File: sather.info,  Node: Array creation expressions,  Next: Bound routine and iter creation expressions,  Prev: Creation expressions,  Up: Expressions

Array creation expressions
==========================

Examples:

     |2,4,6,8|
     |"apple", "orange", "cherry", "kiwi"|

Syntax:

     ARRAY_EXPRESSION => | EXPRESSION_LIST |

Array creation expressions are used to create and directly specify the
elements of an array object. The type is taken to be the declared type
of the context in which it appears and it must be `ARRAY{T}' for some
type `T'. An array creation expression may not appear as the right-hand
side of a `::=' assignment (*note Assignment statements::), as a
routine or iter argument in which the overloading resolution is
ambiguous, or as the object on which a call is made. The types of each
expression in the EXPRESSION_LIST must be subtypes of `T'. The size of
the created array is equal to the number of specified expressions. The
expressions are evaluated left to right and the results are assigned to
successive array elements.


File: sather.info,  Node: Bound routine and iter creation expressions,  Next: Syntactic sugar expressions,  Prev: Array creation expressions,  Up: Expressions

Bound routine and iter creation expressions
===========================================

Examples:

     bind(2.plus(_))
     bind(_:INT.upto!(5))

Syntax:

     BOUND_CREATE_EXPRESSION => ( bind | bind )
        ( [ TYPE_SPECIFIER :: | BOUND_ARGUMENT . ] ( IDENTIFIER | ITER_NAME )
        [ ( BOUND_ARGUMENT { , BOUND_ARGUMENT } ) ] [ : TYPE_SPECIFIER ] )
     
     BOUND_ARGUMENT => EXPRESSION | _ [ : TYPE_SPECIFIER ]

_Bound routines and iters_ generalize the "function pointer" and
"closure" constructs of other languages. They bind a reference to a
routine or iter together with zero or more argument values (possibly
including `self').

The outer part of the expression is `bind(...)' for bound routines and
`bind(...)' for bound iters. These surround an ordinary routine or iter
call in which any of the arguments or `self' may be replaced by the
underscore character `_'. Such unspecified arguments are _unbound_.
Unbound arguments are specified when the bound routine or iter is
eventually called. In forming a bound iter, all arguments marked "!"
must be left unbound. Optional ":TYPE_SPECIFIER" clauses are used to
specify the types of underscore arguments or the return type and may be
necessary to disambiguate overloaded routines or iters.  If `self' is
specified by an underscore without type information, the type is taken
to be `SAME'.

The expressions in this construct are evaluated from left to right and
the resulting values are stored as part of the bound routine or iter.
Bound creation expressions return bound types. As described in *Note
Type specifiers::, the type specifiers for these types have the form:

     BOUND_TYPE_SPECIFIER => ( ROUT | ITER )
        [ { TYPE_SPECIFIER [ ! ] { , TYPE_SPECIFIER [ ! ] } } ]
        [ : TYPE_SPECIFIER ]

These specifiers begin with the keyword `ROUT' for routines and `ITER'
for iters and are followed by the types of the underscore arguments, if
any, enclosed in braces (e.g.  `ROUT{A,B,C}'). These are followed by a
colon and the return type, if there is one (e.g.  `ITER{INT!}:INT').

Each bound routine defines a routine named `call' and each bound iter
defines an iter named `call!'. These have argument and return value
types that correspond to the bound type descriptor. An invocation of
one of these features behaves like a call on the original routine or
iter with the arguments specified by a combination of the bound values
and those provided to `call' or `call!'. The arguments to `call' or
`call!'  match the underscores positionally from left to right (e.g.
`i::=bind(2.plus(_)).call(3)' is equivalent to `i::=2.plus(3)').

Bound types implicitly introduce edges into the type graph. There is an
edge from each bound type T1 to all bound types T2 that satisfy the
_contravariant_ requirement that

  1. Both T1 and T2 are routine types or both are iter types.

  2. T1 and T2 have the same number of arguments, and either both have
     or both do not have a return value.

  3. Each argument type in T1, if there are any, is a _subtype_ of the
     corresponding argument type in T2. Also, in the case of iters,
     either both argument types are marked with "!" or both aren't
     (*note Iter definitions::).

  4. The type of the return value, if any, in T1 is a _supertype_ of
     the corresponding return type in T2.


File: sather.info,  Node: Syntactic sugar expressions,  Next: and expressions,  Prev: Bound routine and iter creation expressions,  Up: Expressions

Syntactic sugar expressions
===========================

Examples:

     a+b
     x<7

Syntax:

     SUGAR_EXPRESSION => EXPRESSION BINARY_OP EXPRESSION
        | - EXPRESSION
        | [ EXPRESSION ] [ EXPRESSION_LIST ]
        | ( EXPRESSION )
     
     BINARY_OP => + | - | * | / | ^ | % | ~ | < | <= | = | /= | > | >=

As shown in the following table, several Sather constructs are simply
_syntactic sugar_ for corresponding routine calls.  Each of these
transformations is applied after the component expressions have
themselves been transformed. The precedence ordering shown determines
the grouping of these forms. Symbols of the same precedence associate
left to right and parentheses may be used for explicit grouping.


               Sugar form                    Translation
     
              EXPR1 + EXPR2                EXPR1.plus(EXPR2)
     
              EXPR1 - EXPR2                EXPR1.minus(EXPR2)
     
              EXPR1 * EXPR2                EXPR1.times(EXPR2)
     
              EXPR1 / EXPR2                EXPR1.div(EXPR2)
     
              EXPR1 ^ EXPR2                EXPR1.pow(EXPR2)
     
              EXPR1 % EXPR2                EXPR1.mod(EXPR2)
     
              EXPR1 < EXPR2                EXPR1.is_lt(EXPR2)
     
              EXPR1 <= EXPR2               EXPR1.is_leq(EXPR2)
     
              EXPR1 = EXPR2                EXPR1.is_eq(EXPR2)
     
              EXPR1 /= EXPR2               EXPR1.is_neq(EXPR2)
     
              EXPR1 > EXPR2                EXPR1.is_gt(EXPR2)
     
              EXPR1 >= EXPR2               EXPR1.is_geq(EXPR2)
     
              - EXPR                       EXPR.negate
     
              ~ EXPR                       EXPR.not
     
              [EXPR_LIST]                    aget(EXPRESSION_LIST)
     
              EXPR1[EXPRESSION_LIST]         EXPR1.aget(EXPRESSION_LIST)
     
              (EXPRESSION)                 EXPRESSION

Table 1: Syntactic sugar expressions and their translations

                          .   ::   []   ()
     
                                 ^
     
                            ~   Unary  -
     
                             *   /   %
     
                           +   Binary  -
     
                       <   <=   =   /=   >=   >
     
                              and   or

Table 2: Precedence ordering of special symbols from strongest to
weakest


File: sather.info,  Node: and expressions,  Next: or expressions,  Prev: Syntactic sugar expressions,  Up: Expressions

`and' expressions
=================

Example:

     0<=x and x<10

Syntax:

     AND_EXPRESSION => EXPRESSION and EXPRESSION

_and expressions_ compute the conjunction of two boolean expressions
and return boolean values. The first expression is evaluated and if
`false', is immediately returned as the result.  Otherwise, the second
expression is evaluated and its value returned.


File: sather.info,  Node: or expressions,  Next: exception expressions,  Prev: and expressions,  Up: Expressions

`or' expressions
================

Example:

     x=2 or x=3

Syntax:

     OR_EXPRESSION => EXPRESSION or EXPRESSION

_or expressions_ compute the disjunction of two boolean expressions and
return boolean values. The first expression is evaluated and if `true',
is immediately returned as the result. Otherwise, the second expression
is evaluated and its value returned.


File: sather.info,  Node: exception expressions,  Next: initial expressions,  Prev: or expressions,  Up: Expressions

`exception' expressions
=======================

Example:

     exception

Syntax:

     EXCEPT_EXPRESSION => EXCEPTION

_exception expressions_ may only appear within the statements of the
`then' and `else' clauses in `protect' statements. They return the
exception object that caused the `when' branch to be taken in the most
tightly enclosing `protect' statement. The return type is the type
specified in the corresponding `when' clause (*note protect
statements::). In an else clause the return type is `$OB'.


File: sather.info,  Node: initial expressions,  Next: result expressions,  Prev: exception expressions,  Up: Expressions

`initial' expressions
=====================

Example:

     initial(a)

Syntax:

     INITIAL_EXPRESSION => initial ( EXPRESSION )

_initial expressions_ may only appear in the `post' expressions of
routines and iters. The EXPRESSION must have a return value and must
not itself contain `initial' expressions. When a routine is called or
an iter resumes it evaluates the EXPRESSION of each `initial'
expression from left to right. When the postcondition is checked at the
end, each `initial' expression returns its precomputed value.


File: sather.info,  Node: result expressions,  Next: while! expressions,  Prev: initial expressions,  Up: Expressions

`result' expressions
====================

Example:

     result

Syntax:

     RESULT_EXPRESSION => result

_result expressions_ may only appear within the postconditions of
routines and iters that have return values and may not appear within
`initial' expressions. They return the value returned by the routine or
yielded by the iter. Their type is the return type of the routine or
iter in which they appear.


File: sather.info,  Node: while! expressions,  Next: until! expressions,  Prev: result expressions,  Up: Expressions

`while!' expressions
====================

Example:

     while!(a<10)

Syntax:

     WHILE!_EXPRESSION => while!( EXPRESSION )

_while! expressions_ are iter calls which take a single boolean
argument that is re-evaluated on each iteration. They `yield' when the
argument is true and `quit' when it is false.


File: sather.info,  Node: until! expressions,  Next: break! expressions,  Prev: while! expressions,  Up: Expressions

`until!' expressions
====================

Example:

     until!(a>10)

Syntax:

     UNTIL!_EXPRESSION => until!( EXPRESSION )

_until! expressions_ are iter calls which take a single boolean
argument that is re-evaluated on each iteration. They `yield' when the
argument is false and `quit' when it is true.


File: sather.info,  Node: break! expressions,  Prev: until! expressions,  Up: Expressions

`break!' expressions
====================

Example:

     break!

Syntax:

     BREAK!_EXPRESSION => break!

_break! expressions_ are iter calls which immediately `quit' when they
are called.


File: sather.info,  Node: Lexical Structure,  Next: Special Features,  Prev: Expressions,  Up: Top

Lexical Structure
*****************

The character set used in Sather source files is implementation
dependent, but it must include at least the characters which appear in
the syntactic constructs in this specification.  Many implementations
will be based on ASCII, but this is not required. The case of characters
in source files is significant. All syntactic constructs except
identifiers and certain literals may be separated by an arbitrary number
of _whitespace_ characters and _comments_.  The seven whitespace
characters are space, tab, newline, vertical tab, backspace, carriage
return, and form feed. Sather comments consist of two dashes `--'
outside of a string (*note String literal expressions::) or character
literal (*note Character literal expressions::) and all following text
until the end of the line.

Sather _identifiers_ are used to name class features and routine and
iter arguments and local variables. Most consist of letters, decimal
digits, and the underscore character, and begin with a letter. Iter
names additionally end with the "!" character. Abstract type names and
class names are similar, but the letters must be uppercase and abstract
type names begin with "$". There are no restrictions on the lengths of
Sather identifiers or class names. Identifiers, class names and keywords
must be followed by a character other than a letter, decimal digit or
underscore. This may force the use of white-space after an identifier.

     IDENTIFIER => LETTER {LETTER | DECIMAL_DIGIT | _}
     
     UPPERCASE_IDENTIFIER => UPPERCASE_LETTER
        {UPPERCASE_LETTER | DECIMAL_DIGIT | _}
     
     ABSTRACT_TYPE_NAME => $ UPPERCASE_LETTER
        {UPPERCASE_LETTER | DECIMAL_DIGIT | _}
     
     ITER_NAME => [IDENTIFIER]!
     
     LETTER => LOWERCASE_LETTER | UPPERCASE_LETTER
     
     LOWERCASE_LETTER => a | b | c | d | e | f | g | h | i | j | k | l | m
        | n | o | p | q | r | s | t | u | v | w | x | y | z
     
     UPPERCASE_LETTER => A | B | C | D | E | F | G | H | I | J | K | L | M
        | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
     
     DECIMAL_DIGIT => 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Sather _keywords_ are used to identify the fundamental syntactic
constructs and may not be used as identifiers. The keywords are:

     KEYWORD => and | assert | attr | break! | case | class | const
        | else | elsif | end | exception | external | false | if
        | include | initial | is | ITER | loop | new | or | post
        | pre | private | protect | quit | raise | readonly | result
        | return | ROUT | SAME | self | shared | then | true | type
        | typecase | until! | value | void | when | while! | yield

The syntax also makes use of the following _special symbols_:

     SPECIAL_SYMBOL => ( | ) | [ | ] | { | } | , | . | ; | : | $ | _ | +
        | - | * | / | = | < | > | # | ^ | % | ~ | | | ! | /= | <=
        | >= | := | :: | ->

In addition to the keywords `ROUT' and `ITER', there are several
reserved names which may not be used to name user classes. Some of
these are the names of built-in library classes known to the compiler,
others are used in special situations as described in *Note Built-in
Classes::.

     SPECIAL_CLASSNAMES => $OB | ARRAY | AREF | AVAL | BOOL | CHAR | EXT_OB
        | FLT | FLTD | FLTX | FLTDX | FLTI | INT | INTI | $REHASH | SAME
        | STR | SYS

There are certain names in the feature namespace which are the
translations of syntactic sugar expressions:

     SUGAR_FEATURENAMES => aget | aset | div | is_eq | is_geq | is_gt | is_leq
        | is_lt | is_neq | minus | mod | negate | not | plus | pow | times

and there are feature names which have a special effect when they are
defined in a class:

     SPECIAL_FEATURENAMES => create | invariant | main

Finally, there are special lexical forms for literal expressions which
define boolean, character, string, integer, and floating point values
as described in the following sections.

* Menu:

* Boolean literal expressions::
* Character literal expressions::
* String literal expressions::
* Integer literal expressions::
* Floating point literal expressions::


File: sather.info,  Node: Boolean literal expressions,  Next: Character literal expressions,  Prev: Lexical Structure,  Up: Lexical Structure

Boolean literal expressions
===========================

Examples:

     true
     false

Syntax:

     BOOL_LITERAL_EXPRESSION => true | false

`BOOL' objects represent boolean values (*note Built-in Classes::). The
two possible values are represented by the _boolean literal
expressions_: `true' and `false'.


File: sather.info,  Node: Character literal expressions,  Next: String literal expressions,  Prev: Boolean literal expressions,  Up: Lexical Structure

Character literal expressions
=============================

Example:

     'a'

Syntax:

     CHAR_LITERAL_EXPRESSION => ' (ISO_CHARACTER | \ ESCAPE_SEQ) '
     
     ESCAPE_SEQ => a | b | f | n | r | t | v | \ | ' | " | OCTAL_DIGIT {OCTAL_DIGIT}

`CHAR' objects represent characters (*note Built-in Classes::).
_Character literal expressions_ begin and end with single quote marks.
These may enclose either any single ISO-Latin-1 printing character
except single quote or backslash or an escape code starting with a
backslash.

The escape codes are interpreted as follows: `'\a'' is an _alert_ such
as a bell, `'\b'' is the _backspace_ character, `'\f'' is the _form
feed_ character, `'\n'' is the _newline_ character, `'\r'' is the
_carriage return_ character, `'\t'' is the _horizontal tab_ character,
`'\v'' is the _vertical tab_ character, `'\\'' is the _backslash_
character, `'\''' is the _single quote_ character, and `'\"'' is the
_double quote_ character. A backslash followed by one or more octal
digits represents the character whose octal representation is given.
The mapping is implementation dependent.


File: sather.info,  Node: String literal expressions,  Next: Integer literal expressions,  Prev: Character literal expressions,  Up: Lexical Structure

String literal expressions
==========================

Examples:

     "a string literal"
     "concat" "enation"

Syntax:

     STR_LITERAL_EXPRESSION => "{ISO_CHARACTER}" {"{ISO_CHARACTER}"}

`STR' objects represent strings (*note Built-in Classes::). _String
literal expressions_ begin and end with double quote marks. The
characters making up the string are specified in this construct from
left to right. A backslash starts an escape sequence as with character
literals. All successive octal digits following a backslash are taken
to define a single character. Individual double-quote-bounded segments
of string literals may not extend beyond a single line in the source
text. However, successive quote bounded segments are concatenated
together to form a single string and can be used to allow string
literals to span more than one line of source code. They may also be
used to force the end of an octal encoded character. For example:
`"\0367"' is a one character string, while `"\03""67"' is a three
character string. Such segments may be separated by comments and
whitespace.


File: sather.info,  Node: Integer literal expressions,  Next: Floating point literal expressions,  Prev: String literal expressions,  Up: Lexical Structure

Integer literal expressions
===========================

Examples:

     14
     14i
     -4532
     39_832_983_298
     0b101011
     -0b_10111010_00101100_01010101
     0o372363i
     Ox_e98a_7c4d_65d7_6aa6_932d

Syntax:

     INT_LITERAL_EXPRESSION => [-] (BINARY_INT | OCTAL_INT
        | DECIMAL_INT | HEX_INT) [i]
     
     BINARY_INT => 0b {BINARY_DIGIT | _}
     
     BINARY_DIGIT => 0 | 1
     
     OCTAL_INT => 0o {OCTAL_DIGIT | _}
     
     OCTAL_DIGIT => 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
     
     DECIMAL_INT => DECIMAL_DIGIT {DECIMAL_DIGIT | _}
     
     HEX_INT => 0x {HEX_DIGIT | _}
     
     HEX_DIGIT => DECIMAL_DIGIT | a | b | c | d | e | f

`INT' objects represent machine integers and `INTI' objects represent
infinite precision integers (*note Built-in Classes::). The literal
form for `INTI' objects ends with a trailing `i'. A leading `-' sign is
used to denote a negative integer. Integer literals can be represented
in four bases: binary is base 2, octal is base 8, decimal is base 10
and hexadecimal is base 16. These are indicated by the prefixes: `0b',
`0o', nothing, and `0x' respectively. Underscores may be used within
integer literals to improve readability and are ignored. `INT' literals
are only legal if they are in the representable range.


File: sather.info,  Node: Floating point literal expressions,  Prev: Integer literal expressions,  Up: Lexical Structure

Floating point literal expressions
==================================

Examples:

     12.34
     3.4e-8d
     3.498_239_832_932_988_9e22x
     2.2i

Syntax:

     FLT_LITERAL_EXPRESSION => [-] DECIMAL_INT . DECIMAL_INT
        [e [-] DECIMAL_INT] [d | x | dx | i]

`FLT', `FLTD', `FLTX', and `FLTDX' objects represent floating point
numbers according to the single, double, extended, and double extended
representations defined by the IEEE-754-1985 standard and `FLTI'
objects represent arbitrary precision floating point numbers (*note
Built-in Classes::).  _Floating point literal expressions_ of these
types are indicated by the suffixes: nothing, `d', `x', `dx', and `i',
respectively. The optional `e' portion is used to specify a power of 10
by which to multiply the decimal value. Underscores may be used within
floating point literals to improve readability and are ignored. Literal
values are only legal if they are within the range specified by the
IEEE standard.


File: sather.info,  Node: Special Features,  Next: Built-in Classes,  Prev: Lexical Structure,  Up: Top

Special Features
****************

This section describes several features of classes that are
automatically defined or have special properties.

* Menu:

* invariant::
* main::


File: sather.info,  Node: invariant,  Next: main,  Prev: Special Features,  Up: Special Features

`invariant'
===========

If a routine with the signature `invariant:BOOL', appears in a class,
it defines a class invariant. It is a fatal error for it to evaluate to
false after any public routine or iter of the class returns or yields.


File: sather.info,  Node: main,  Prev: invariant,  Up: Special Features

`main'
======

A non-parameterized value or reference class is specified when a Sather
program is compiled. This class must define a routine named `main'.
When the program executes, an object of the specified type is created
and `main' is called on it. If `main' is declared to have an argument
of type `ARRAY{STR}', it will be passed an array of any command line
specified when the program is called. If it is declared to have a
return value of type `INT', this will specify the exit code of the
program when it finishes execution.


File: sather.info,  Node: Built-in Classes,  Next: Interfacing with other Languages,  Prev: Special Features,  Up: Top

Built-in Classes
****************

This section provides a short description of classes that are a part of
every Sather implementation and which may not be modified. The detailed
semantics and precise interface are specified in the class library
documentation.

   * `$OB' is automatically a supertype of every type. Variables
     declared by this type may hold any object. It has no features.

   * `AREF{T}' is a reference array class. Any reference class which
     includes it obtains an array of elements of type `T' in addition to
     any attributes it has defined. In such classes, `new' has a single
     integer argument that specifies the size of the array portion.  It
     defines routines and iters named: `asize', `aget', `aset',
     `aclear', `acopy', `aelts!', `aset_elts!', and `ainds!'. Array
     indices start at zero.

   * `AVAL{T}' is the value class analog of `AREF'. Classes which
     include `AVAL' must define `asize' as an integer constant which
     determines the size of the array portion.

   * `ARRAY{T}' defines general purpose array objects. They may be
     directly constructed by array creation expressions (*note Array
     creation expressions::).

   * `TUP' names a set of parameterized value types called tuples, one
     for each number of parameters. Each has as many attributes as
     parameters and they are named `t1', `t2', etc. Each is declared by
     the type of the corresponding parameter (e.g. `TUP{INT,FLT}' has
     attributes `t1:INT' and `t2:FLT'). It defines `create' with an
     argument corresponding to each attribute.

   * `BOOL' defines value objects which represent boolean values. The
     initial value is `false'.

   * `CHAR' defines value objects which represent characters. The number
     of bits in a `CHAR' object must be less than or equal to the number
     in an `INT' object. The initial value is `'\0''.

   * `STR' defines reference objects which represent strings.

   * `INT' defines value objects which represent machine-dependent
     integers. The size is implementation dependent but must be at
     least 32 bits. The two's complement representation is used to
     represent negative values. Bit operations are supported in
     addition to numerical operations.

   * `INTI' defines reference objects which represent infinite precision
     integers.

   * `FLT', `FLTD', `FLTX', and `FLTDX' define value objects which
     represent floating point values according to the single, double,
     extended, and double extended representations defined by the
     IEEE-754-1985 standard.

   * `FLTI' defines reference objects which represent arbitrary
     precision floating point objects.

   * `EXT_OB' is used to refer to "foreign pointers". These might be
     used, for example, to hold references to C structures. Such
     pointers are never followed by Sather and are treated essentially
     as integers which disallow arithmetic operations. They may be
     passed to external routines.

   * `SYS' defines a number of routines for accessing system
     information.  `tp(ob:$OB):TYPE' returns the type of an object.
     `destroy(ob:$OB)' explicitly deallocates an object (Sather is
     garbage collected and this is only done for efficiency reasons in
     special circumstances). `id(ob:$OB):INT' returns an integer id
     associated with a particular object.  `ob_eq(o1,o2:$OB):BOOL' is
     used to test two objects for equality.

   * `$REHASH' defines the single routine `rehash'. Any class whose
     objects need to perform special operations when they are moved or
     copied should be a subtype of it. The `rehash' routine is called
     on such objects if the system changes their location during
     garbage collection.


File: sather.info,  Node: Interfacing with other Languages,  Next: Acknowledgements,  Prev: Built-in Classes,  Up: Top

Interfacing with other Languages
********************************

External classes are used to interface with code from other languages.
Each external class is typically associated with an object file compiled
from a language like C or Fortran. External classes do not support
subtyping, implementation inheritance, or overloading. External class
bodies consist of a list of routine definitions. Routines with no body
specify the interface for Sather code to call external code. Routines
with a body specify the interface for external code to call Sather code.

Each routine name without a body may only appear once in any external
class and the corresponding external object file must provide a
conforming function definition. Sather code may call these external
routines using a class call expression of the form
`EXT_CLASS::ext_rout(5)'. External code may refer to an external
routine with a body by concatenating the class name, an underscore, and
the routine name (e.g. `EXT_CLASS_sather_rout').

Only a restricted set of types are allowed for the arguments and return
values of these calls.  The built-in value types `BOOL', `CHAR', `INT',
`FLT', `FLTD', `FLTX', and `FLTDX' are allowed anywhere and on each
machine have the format supported by the C compiler used to compile
Sather for that machine. The type `EXT_OB' is also allowed anywhere and
is used to reference storage allocated by the external language. Sather
cannot follow these pointers.

To enhance the efficiency of the interface, the arguments of external
routines without bodies may also be declared by types which have include
paths to `AREF{CHAR}', `AREF{INT}', `AREF{FLT}', `AREF{FLTD}',
`AREF{FLTX}', `AREF{FLTDX}', or `AREF{EXT_OB}'. When a Sather program
calls such a routine, the external routine is passed a pointer into
just the array portion of the object; if `void' is passed, the C
routine will receive a `NULL' pointer.  The external routine may modify
the contents of this array portion, but must not store the pointer.
There is no guarantee that the pointer will remain valid after the
external routine returns. These restrictions help to ensure that the
Sather type system and garbage collector will not be corrupted by
external code while not sacrificing efficiency for the most important
cases.


File: sather.info,  Node: Acknowledgements,  Next: Concept Index,  Prev: Interfacing with other Languages,  Up: Top

Acknowledgements
****************

Sather has adopted ideas from a number of other languages. Its primary
debt is to Eiffel, designed by Bertrand Meyer, but it has also been
influenced by C, C++, Cecil, CLOS, CLU, Common Lisp, Dylan, ML,
Modula-3, Oberon, Objective C, Pascal, SAIL, School, Self, and
Smalltalk. Many people have been involved in the language design
discussions including: Subutai Ahmad, Krste Asanovic, Jonathan Bachrach,
David Bailey, Joachim Beer, Jeff Bilmes, Peter Blicher, John Boyland,
Matthew Brand, Henry Cejtin, Richard Durbin, Jerry Feldman, Carl
Feynman, Ben Gomes, Gerhard Goos, Robert Griesemer, Hermann Haertig, Ari
Huttunen, Roberto Ierusalimschy, Phil Kohn, Franz Kurfess, Chu-Cheow
Lim, Franco Mazzanti, Stephan Murer, Thomas Rauber, Steve Renals, Noemi
de La Rocque Rodriguez, Hans Rohnert, Heinz Schmidt, Carlo Sequin,
Andreas Stolcke, David Stoutamire, Clemens Szyperski, Martin Trapp and
Bob Weiner.


File: sather.info,  Node: Concept Index,  Next: Keyword and Built-in Index,  Prev: Acknowledgements,  Up: Top

Concept Index
*************

* Menu:

* Abstract type definitions:             Abstract type definitions.
* Acknowledgements:                      Acknowledgements.
* and expressions:                       and expressions.
* Array creation expressions:            Array creation expressions.
* assert statements:                     assert statements.
* Assignment statements:                 Assignment statements.
* Boolean literal expressions:           Boolean literal expressions.
* Bound routine and iter creation expressions: Bound routine and iter creation expressions.
* break! expressions:                    break! expressions.
* Built-in Classes:                      Built-in Classes.
* case statements:                       case statements.
* Character literal expressions:         Character literal expressions.
* Class Elements:                        Class Elements.
* Classes:                               Classes.
* Constant attribute definitions:        Constant attribute definitions.
* Creation expressions:                  Creation expressions.
* Declaration statements:                Declaration statements.
* exception expressions:                 exception expressions.
* Expression statements:                 Expression statements.
* Expressions:                           Expressions.
* Floating point literal expressions:    Floating point literal expressions.
* if statements:                         if statements.
* include clauses:                       include clauses.
* initial expressions:                   initial expressions.
* Integer literal expressions:           Integer literal expressions.
* Interfacing with other Languages:      Interfacing with other Languages.
* Introduction:                          Introduction.
* invariant:                             invariant.
* Iter definitions:                      Iter definitions.
* Lexical Structure:                     Lexical Structure.
* Local variable access expressions:     Local variable access expressions.
* loop statements:                       loop statements.
* main:                                  main.
* new expressions:                       new expressions.
* Object attribute definitions:          Object attribute definitions.
* or expressions:                        or expressions.
* protect statements:                    protect statements.
* quit statements:                       quit statements.
* raise statements:                      raise statements.
* result expressions:                    result expressions.
* return statements:                     return statements.
* Routine and iter call expressions:     Routine and iter call expressions.
* Routine definitions:                   Routine definitions.
* Sather source files:                   Sather source files.
* self expressions:                      self expressions.
* Shared attribute definitions:          Shared attribute definitions.
* Special Features:                      Special Features.
* Statements:                            Statements.
* String literal expressions:            String literal expressions.
* Syntactic sugar expressions:           Syntactic sugar expressions.
* Type specifiers:                       Type specifiers.
* typecase statements:                   typecase statements.
* Types and Classes:                     Types and Classes.
* until! expressions:                    until! expressions.
* void expressions:                      void expressions.
* void test expressions:                 void test expressions.
* while! expressions:                    while! expressions.
* yield statements:                      yield statements.


File: sather.info,  Node: Keyword and Built-in Index,  Prev: Concept Index,  Up: Top

Keyword and Built-in Index
**************************

* Menu:

* !:                                     Lexical Structure.
* ":                                     String literal expressions.
* $:                                     Lexical Structure.
* $OB:                                   Built-in Classes.
* $REHASH:                               Built-in Classes.
* %:                                     Syntactic sugar expressions.
* ':                                     Character literal expressions.
* *:                                     Syntactic sugar expressions.
* +:                                     Syntactic sugar expressions.
* -:                                     Syntactic sugar expressions.
* --:                                    Lexical Structure.
* /:                                     Syntactic sugar expressions.
* /=:                                    Syntactic sugar expressions.
* 0b:                                    Integer literal expressions.
* 0o:                                    Integer literal expressions.
* 0x:                                    Integer literal expressions.
* <:                                     Syntactic sugar expressions.
* <=:                                    Syntactic sugar expressions.
* =:                                     Syntactic sugar expressions.
* >:                                     Syntactic sugar expressions.
* >=:                                    Syntactic sugar expressions.
* [:                                     Syntactic sugar expressions.
* \:                                     Character literal expressions.
* ]:                                     Syntactic sugar expressions.
* ^:                                     Syntactic sugar expressions.
* aget:                                  Syntactic sugar expressions.
* and:                                   and expressions.
* AREF:                                  Built-in Classes.
* ARRAY:                                 Built-in Classes.
* assert:                                assert statements.
* attr:                                  Object attribute definitions.
* AVAL:                                  Built-in Classes.
* bind:                                  Bound routine and iter creation expressions.
* BOOL:                                  Built-in Classes.
* break!:                                break! expressions.
* case:                                  case statements.
* CHAR:                                  Built-in Classes.
* class:                                 Classes.
* const:                                 Constant attribute definitions.
* create:                                Creation expressions.
* div:                                   Syntactic sugar expressions.
* else:                                  if statements.
* elsif:                                 if statements.
* end:                                   Abstract type definitions.
* exception:                             exception expressions.
* EXT:                                   Built-in Classes.
* external:                              Classes.
* false:                                 Boolean literal expressions.
* FLT:                                   Built-in Classes.
* FLTD:                                  Built-in Classes.
* FLTDX:                                 Built-in Classes.
* FLTI:                                  Built-in Classes.
* FLTX:                                  Built-in Classes.
* if:                                    if statements.
* include:                               include clauses.
* initial:                               initial expressions.
* INT:                                   Built-in Classes.
* INTI:                                  Built-in Classes.
* invariant:                             invariant.
* is:                                    Abstract type definitions.
* is_eq:                                 Syntactic sugar expressions.
* is_geq:                                Syntactic sugar expressions.
* is_gt:                                 Syntactic sugar expressions.
* is_leq:                                Syntactic sugar expressions.
* is_lt:                                 Syntactic sugar expressions.
* is_neq:                                Syntactic sugar expressions.
* ITER:                                  Type specifiers.
* loop:                                  loop statements.
* main:                                  main.
* minus:                                 Syntactic sugar expressions.
* mod:                                   Syntactic sugar expressions.
* negate:                                Syntactic sugar expressions.
* new:                                   new expressions.
* not:                                   Syntactic sugar expressions.
* or:                                    or expressions.
* plus:                                  Syntactic sugar expressions.
* post:                                  Routine definitions.
* pow:                                   Syntactic sugar expressions.
* pre:                                   Routine definitions.
* private:                               Constant attribute definitions.
* protect:                               protect statements.
* quit:                                  quit statements.
* raise:                                 raise statements.
* readonly:                              Shared attribute definitions.
* result:                                result expressions.
* return:                                return statements.
* ROUT:                                  Type specifiers.
* SAME:                                  Type specifiers.
* self:                                  self expressions.
* shared:                                Shared attribute definitions.
* STR:                                   Built-in Classes.
* SYS:                                   Built-in Classes.
* then:                                  if statements.
* times:                                 Syntactic sugar expressions.
* true:                                  Boolean literal expressions.
* TUP:                                   Built-in Classes.
* type:                                  Abstract type definitions.
* typecase:                              typecase statements.
* until!:                                until! expressions.
* value:                                 Classes.
* void <1>:                              void expressions.
* void:                                  void test expressions.
* when:                                  case statements.
* while!:                                while! expressions.
* yield:                                 yield statements.
* ~:                                     Syntactic sugar expressions.



Tag Table:
Node: Top995
Node: Introduction1421
Node: Types and Classes5036
Node: Sather source files8252
Node: Abstract type definitions8922
Node: Classes13289
Node: Type specifiers15626
Node: Class Elements17163
Node: Constant attribute definitions18270
Node: Shared attribute definitions20437
Node: Object attribute definitions21887
Node: Routine definitions23984
Node: Iter definitions25984
Node: include clauses27292
Node: Statements30012
Node: Declaration statements31143
Node: Assignment statements32129
Node: if statements34732
Node: loop statements35640
Node: yield statements37114
Node: quit statements37783
Node: return statements38194
Node: case statements39154
Node: typecase statements40477
Node: assert statements42314
Node: protect statements42665
Node: raise statements44498
Node: Expression statements44952
Node: Expressions45303
Node: self expressions46668
Node: Local variable access expressions47127
Node: Routine and iter call expressions47895
Node: void expressions50763
Node: void test expressions52326
Node: new expressions52717
Node: Creation expressions53451
Node: Array creation expressions54641
Node: Bound routine and iter creation expressions55702
Node: Syntactic sugar expressions59177
Node: and expressions61719
Node: or expressions62224
Node: exception expressions62713
Node: initial expressions63348
Node: result expressions64007
Node: while! expressions64541
Node: until! expressions64972
Node: break! expressions65403
Node: Lexical Structure65689
Node: Boolean literal expressions69935
Node: Character literal expressions70392
Node: String literal expressions71666
Node: Integer literal expressions72906
Node: Floating point literal expressions74348
Node: Special Features75448
Node: invariant75734
Node: main76073
Node: Built-in Classes76682
Node: Interfacing with other Languages80547
Node: Acknowledgements82956
Node: Concept Index84014
Node: Keyword and Built-in Index87801

End Tag Table
