# Introductory Notes:
Sather Programming Language

The programming language Sather was originally designed and developed at the International Computer Science Institute (ICSI) affiliated to the department of computer science of the University of California at Berkeley.

The language takes its' name from the Sather tower - the best-known landmark on the Berkeley campus. The tower was designed as a copy of St Mark's Campanile in Venice, Italy.

Sather was originally envisaged as an efficient, cleaned up, alternative to the language Eiffel. Since its conception, however, the two languages have evolved to be quite distinct. Sather's principal features are :-

- It is designed to be used in a garbage collected environment.
- There are NO implicitly constructed objects used at run-time - behind the user's back (as it were). This extends to the programmer having to write code to construct an object explicitly.
- There are NO implicit type conversions.
- As a result of the previous two features, the language has been specified to support overloading of methods - easily resolved at compile time by an implementation.
- The concepts of inheritance and of code inclusion are completely separate; the first is provided by the introduction of abstract classes and sub-typing, while the second is provided for by the use of one (or more) include clauses in a class definition. The introduction of partial classes which may be included in an implementation class source text also supports cleaner design of code.
- Iterators (known as iters) were introduced in version 1.0 of the language. These are methods which encapsulate user-defined looping control structures. Their use simplifies both run-time code generated and the definition of looping of all kinds for the programmer.
- Sather provides higher-order functions through the use of method closures. One or more arguments may be bound to the method (routine or iter) at any stage between definition and eventual calling. These are most useful for building control structures at run-time - for example providing call-back methods for a windowing system.
- Sather provides both reference and immutable objects, carefully distinguishing between them when defining a class implementation. Immutable types have no heap overhead, but they require the entire object to be passed (however large it may be) as a parameter to a method call. This is only a disadvantage for objects with many components. Such things as, for example, a complex number class would only contain two numeric components, each of which itself is of an immutable class.
- Sather provides several safety features, including full bounds and reference checking. Programmer defined "contracts" may be specified for any method as pre and post conditions. Assertions and class invariants are also available.
- Facilities for writing programs which are both concurrent and distributed are built into the language specification.

## Language Specification

A formal language specification is in the course of being written.

## Required Library

The formal definition of the Sather language includes only three pervasive implementation classes - BIT, BOOL and REFERENCE. There is also a small number of pervasive abstract classes and "constructor" classes which provide the basis on which all other classes may be defined. In order to provide a practically useful implementation it has been decided that an implementation which conforms to the specification must also include classes specified in a Required Library (everything from bit-patterns to text, from date/time to file systems, etc).

## Additional Libraries

It is expected that implementers or, indeed, library users too will offer additional libraries as they deem fit. It is expected that these will include such general topics as Windowing, Networks, Mathematics and specialist extensions of the Required Library. Some notes on libraries in general will be found in the library documentation of the Sather 1.3 implementation of the language.

## Localisation Resources

The formal specification of the Sather language includes a reference to the need for an implementation to provide facilities for internationalising programs and providing localisation facilities. The model specified includes the implementation of the two standards -

> ISO/IEC 14651 - International String Ordering - Method for comparing Character Strings and Description of the Common Template Tailorable Ordering

> ISO/IEC 14652 - Information Technology - Specifications for Cultural Conventions

These standards are available from national standards bodies, a list of whose members may be obtained from ISO.

## Culture, Resources and Coding

The need to be able to run a program without alteration in whatever cultural environment it may be has meant that the Required Library include a number of classes specifically for use where a variety of cultures could be in use. Any full implementation of the internationalised Sather language must therefore include facilities for converting a cultural specification (as given in the appropriate standards and as may be registered with national standards bodies) into a form suitable for use when running Sather programs.

Since "message" files may be needed not only in a variety of natural languages, but also in a range of encodings, it is, as a minimum, necessary to have the ability to convert from one encoding to another. This requires an implementation also to provide such a re-encoding utility.

Comments or enquiries should be made to Keith Hopper . Page last modified: Tuesday, 24 October 2000. |