Converting your code to Sather 1.1

There are numerous changes that have occured in 1.1. Some of the conversion can be performed automagically by the compiler, while changes involving the library will have to be done by hand.

The language changes that can be handled by the compiler are the following:

Some language changes that are not handled by the compiler are the following:

The non-language changes involve fairly extensive changes to the library. The most important are the following:

Recommended conversion procedure

You should now have compile-ready 1.1 code.

Why change $IS_EQ?

These changes in handling equality have been made after a lot of discussion. Our final, relatively minimal changes, solve a couple of problems. This is a very brief description of why we did what we did. For a more complete discussion of the problem, visit us.

The first problem is that sometimes the equality and hash routines were being used inconsistently - a container class should never use the is_eq routine of an object, while not using the corresponding hash routine. The reason that this might happen is related to the second problem - sometimes an object (say foo) might not be under the $IS_EQ{T} that the container expects, and so it defaults back to using SYS::ob_eq instead of foo.is_eq, while foo.hash continues to be used. Hence, we placed $HASH < $IS_EQ, and always use $HASH in the typecases of container classes.

The second problem was caused by the parametrization of $IS_EQ.

FOO < $IS_EQ{FOO}, $FOO
In LIST{T} we have
   elt_eq(e1,e2: T) is
	typecase e1
	when $IS_EQ{T} then return e1.is_eq(e2)
	else return SYS::ob_eq(e1,e2); end;
    end;
LIST{FOO} will work correctly and use FOO's is_eq routine. The first branch of the typecase will be chosen. However, when we place a FOO in a LIST{$FOO}, FOO's is_eq routine cannot be used. The second branch of the typecase will be chosen. (FOO is not under $IS_EQ{$FOO}). This can lead to fairly subtle bugs.

A word to the contravariant-wise - if we had subtyping relationships between parametrized classes (which requires distinguishing between parameters that are used as arguments, return types or both), the second problem would go away.