Frequently Asked Questions about Sather

---

What is Sather?

Sather has garbage collection, statically-checked strong typing, multiple inheritance, separate implementation and type inheritance, parameterized classes, dynamic dispatch, iteration abstraction, higher-order routines and iters, exception handling, assertions, preconditions, postconditions, and class invariants. Sather code can be compiled into C code and can efficiently link with C object files.

---

Where does the name ``Sather'' come from? How do I pronounce it?

---

What does the ``Hello World'' program look like?

    class MAIN
    is
        main
        is
            #OUT + "Hello World!\n";
	end; -- main

    end; -- class MAIN 

---

Where can I get information on Sather?

---

Are there freely available implementations of Sather?

---

What's the difference between Sather and Sather-K?

---

What is the future of Sather?

---

How efficient is the code?

Most importantly, have enough physical RAM. 32MB is much superior to 16 MB. 32 should be enough for most things, except perhaps recompiling the compiler again. Netscape is a memory hog. Quit it. Besides, you have to do real work sometime.

Secondly, the default compiler flags are not tuned to make the fastest compilation, but to generate the fastest or safest executables. Do not use "-O_fast" until the final production stages: the loop and subexpression optimizations are surprisingly slow and memory-consuming.

Stage1: Compilation errors

-only_check		-- Just report errrors, do not generate any code

Stage2: Debugging

-chk			-- Turn on all checking in all classes
			--  - slows down resulting executable, 
			-- but it should never crash
-debug_source		-- Debugging with source line numbers
-debug_no_backtrace     -- Stack information is expensive. 
 -- You can usually make do by using gdb and printing the stack
 -- using the command 'bt'

To get extra debugging information, such as a full backtrace of the stack whenever a crash occurs, use the option

-debug			-- More debugging information

Production Code Generation

 
-output_C                       -- This is VERY important!  If you don't
                                -- do this you will never get incremental
                                -- C compilation.
-only_reachable                 -- Alternatively, since unreachable code
				-- is only checked after the executable is
				-- generated, you can kill the compile when 
				-- it says ``Checking unreachable...''
 
-O_inline_routines 30           -- These strongly help executable performance
-O_inline_iters 30              -- but don't add much to compile time.
-replace_iters 
 
-chk_no_void all                -- Turn off expensive checking options
-chk_no_bounds all			
-chk_no_pre all
-chk_no_assert all
 

---

How do function and iterator calls get inlined?
Is there a way to specify different levels of inlining?
What performance benefits are there?
What is the result of inlining on the size of executable?

A heuristic approach is used to determine which routines and iterators are simple enough to be inlined. Complexity is computed by traversing the abstract machine representation of the function body. Weights are assigned to all expressions and statements. Calls are replaced if the computed function weights are less than a specified threshold value. Some statements or expressions are never inlined, including "raise" and "loop".

The "-O_fast" and "-O" options provide default inlining for function and iterators. The "-inline" option just turns on the inlining without affecting anything else. By default inlining uses the inlining threshold set to 16 statements plus expressions, which was experimentally found to be optimal for a few applications including the compiler running on a Sparcstation 10.

The optimal inlining threshold is dependent on the application and underlying architecture and for exotic machines may be somewhat different from the default level. To specify inlining with the threshold different from default can use one of the following options:

    -O_inline_routines <threshold>
    -O_inline_iters <threshold>

The reported performance improvements are between 10% and 40%. I/O intensive applications are less affected by inlining. The default threshold inlines 40% of all calls in the compiler itself.

Surprisingly, moderate levels of inlining have not appeared to have negative consequences on the executable size. In fact, default inlining might even slightly reduce the generated executable. The benefits are dependent on the underlying architecture and parameter passing conventions.

Iterators are as efficient as standard loops when they are built-in or inlined (they are converted into standard C loops). In other cases they are probably significantly better than the "iterator objects" i.e. cursors, that might otherwise be required. Simple iterators are inlined. In order to be inlined, an iterator must have at most one yield, and the yield must not be in a conditional statement. i.e. the iterator definition must be of the form:

iter_def!( ) is
  iter_init;
  loop 
    ... code before the yield
    yield (only one, and not in an if statement)
    ... code after the yield
  end;
  other_code;
end;

Routines are inlined if they contain only a single return statement at the end of the routine, and do not contain any "raise" statement.

See the next section for some other options to produce fast code.

Some preliminary experiments on inlining can be found at

---

What optimizations does the compiler currently do?
What options do I use?

-O_inline (Inlining)

Inlining replaces function and procedure calls with the bodies of the respective functions/procedures. It is also able to inline some iterators. The goal is to avoid the overhead of calls. For example, when this option is used, about 80% of all calls are inlined for Sather compiler itself (written in Sather). See above.

-O_cse (Common Subexpression Elimination)

Common subexpressions are eliminated with this option.

-O_move_while Move (While! and Until!)

If a while! or until! is at the beginning of the loop, this option moves it to the end and encloses the loop in an if statement. This allows us to move more loop constants and iter initializations out of the loop.

-O_hoist_iter_init (Hoist Iter Once Arguments)

In many cases, it is possible to move the initialization of once arguments of iters out of the loop. This makes the loop smaller and removes an if statement in the loop.

-O_hoist_const (Hoist Loop Invariants)

Loop constants should be evaluated only once, outside the loop. If this option is used, but hoisting of iter initialization is not, many initializations of once arguments are still hoisted, although this option is less aggressive than the one above.

gomes@icsi.berkeley.edu:	General Library, Browser, graph classes, neural nets
mbk@inls1.ucsd.edu:	Matrix/vector, numerical, fortran
lewikk@aud.alcatel.com:	Emacs support
cbitmead@versant.com:	New file classes
haps@inf.tu-dresden.de:	INTI, FLTI based on GNU MP
sather-bugs@icsi.berkeley.edu:	General questions

There is a more comprehensive list of people at

---

What is all this about covariance vs. contravariance?

---

Why is the order of evaluation of arguments defined?

A frequently cited reason for not specifying an order of evaluation is to allow the compiler to choose an order of evaluation which leads to the most efficient code; for example, simple arguments can be evaluated after complicated ones to relieve register pressure. This can also be done for ordered Sather arguments in the absence of side effects.

While the order is unspecified in C, the evaluations of arguments must appear to occur in _some_ order, not interleaved in execution. (In the extreme this would allow C compilers to fork threads when evaluating arguments, a practice which would break most existing code.) Since a compiler capable of taking advantage of the parallelism made available by unordered arguments must do dependency analysis to make sure the generated instructions appear to evaluate the arguments in some order, such a compiler would of course be able to do the same dependency analysis and instruction reordering on arguments required to be observed evaluating left to right. The generated code would only be different if there were side effects in an argument evaluation which would make the order of evaluation important; and such code would clearly be in error if the argument order was unspecified.

    class MAIN is
        main is
            br::=bind(_:INT.plus(_));   -- Notice the :INT
            #OUT + "1 + 2 = " + br.call(1,2) + '\n';
        end;
    end;

   class MAIN is
	foo is ... end;
	foo: INT is ... end;

	main is
	   a: ROUT := bind(foo);     -- Selects the first "foo"
	   b: ROUT:INT := bind(foo); -- Selects the second "foo"
	end;
   end;	

---

Renaming a feature in an include statement only renames the feature itself, not the calls on that feature. What do I do?

    class A is 
        foo is ... end;
        bar is ...  ... end;
    end;

    class B is
        include A foo->old_foo; -- Wants uses in bar to be renamed as well
        foo is ... end;
    end;

    class A is 
        foo is ... end;
        foo2 is foo; end;
        bar is ...  end;
    end;

    class B is
        include A foo->old_foo;
        foo is ... end;
        foo2 is old_foo; end;
    end;

---

I don't understand immutable classes.
How come I can't use the "a.b:=c" syntax for assigning attributes?

Languages that operate only over immutable objects are called functional languages; operations defined over immutable types are side-effect free and therefore referentially transparent (any given expression always evaluates to the same result). There are many ways to implement immutable objects. Immutable objects may be implemented as actual values (primitive or composite) or as references to actual values or even as applied closures yielding actual values, but in all cases the value of the immutable object is the same and never changes for as long as it exists. In contrast, languages like Sather also provide reference objects, which are best used to model entities that have an identity plus a current state. The idea of an object identity bound to a modifiable state introduces side effects into the language, which can make expressions referentially opaque (an expression involving a reference object may evaluate to a different result each time that it is invoked).

Sather distinguishes between reference and immutable objects at the level of types. Instances of immutable types have value semantics: once created they never change, and there is no such thing as a "reference" to a immutable object. Reference objects have an identity and the state of a reference object can be modified by writing to its attributes.

Logically, when immutable objects are passed as arguments, their value is first copied and then the operations are invoked on the copy. The special properties of immutable objects make them especially amenable to compiler optimizations; a immutable object may be copied freely without the possibility of aliasing conflicts, allowing them to be kept in registers or efficiently stored on the stack without requiring heap allocation.

A variable of abstract type can be used to store either immutable or reference objects. Because it is desirable to make is possible to replace any concrete type by an abstraction, it is necessary for immutable types and reference types to have the same semantics with respect to assignment, passing arguments to functions, and applying the dot "." operator. It is possible to make reference types behave with value semantics by coding them with this in mind; for example, the Sather INTI class (infinite-precision integer) returns a new INTI on modification. This makes it possible to substitute either an INTI or an INT into code using only standard integer operations; more generally, it would be possible to make an abstract class $INTEGER defining an interface that such code had to conform to regardless of the implementation.

The immutable nature of immutable types means that the implicit routines that set attributes return a new object rather than modifying the old one in place. For this reason, the syntax "a.b:=c" is not legal, because it is really syntactic sugar for "a.b(c)". For a immutable class, this routine "b" has a return value which must be used in the calling context. Therefore this example should have been written "a:=a.b(c)". Notice that if you are setting multiple fields, one can conveniently string them together "a:=a.b(c).d(e).f(g)".

If this seems unnatural, consider how operations work on integers: when subtracting five from seven to get two, one isn't modifying "the" seven, turning all sevens into twos; logically one makes a new integer instead of modifying an existing one in place. Similarly, bitfield operations like AND and OR conceptually create a new integer rather than modifying one in place. It just isn't reasonable to have reference semantics on basic types. Sather allows arbitrary classes to have compiler enforced value semantics. Here's what a complex number class might look like (this is a simplified fragment of the complex number class found in the library)

	immutable class CPX is
	    attr re: FLT;
	    attr im: FLT;

	    create(r,i: FLT): SAME is
	       res: SAME;         -- res is a CPX immutable object
	       res := res.re(r);  -- Create a new value with re = r 
				  -- and reassign it to the result
	       res := res.im(i);
	       return res;
	       -- Or, more concisely:    return re(r).im(i);
	    end;	
		
	    main is
		a: CPX;
		a := a.re(5.0);  -- Set the real part to 5.0 -- 
	    end; 
	end; 

---

How (in)expensive are immutable classes like TUP, CPX, etc.?

An `out' argument is passed from the called method to the caller when the called method is returned. It is a fatal error for the called method to examine the value of out argument before assigning to it.

An `inout' argument is passed to the called method and then back to the caller when the method returns. Modifications to `inout' arguments are not observed by the caller until the method returns (value-result semantics).

Remember that argument modes are specified both at the method definition and method call. Some examples of usage are given below. Test/test-out.sa contains a variety of other examples. For more information on argument modes refer to pp.43,44 of Sather 1.1 manual.

type $A is swap(inout a:INT, inout b:INT); bar!(out c:INT!, d:INT); end; class A < $A is swap(inout a:INT, inout b:INT) is t:INT := a; a := b; b := a; end; bar!(out c:INT!, d:INT) is loop i::=1.upto!(d); c := i; yield; end; end; create:SAME is return new; end; end; class MAIN is main is a:A:=#; i::=1; j::=2; a.swap(inout i, inout j); loop a.bar!(out i, 20); end; end; end;

Last change: 7/16/96 The Sather Team (sather@icsi.berkeley.edu)