TooL is a polymorphic pure object-oriented language with classes and inductively defined subtyping rules. TooL supports the classical object model where objects are viewed as abstract data types encapsulating both state and behaviour. Method dispatch is based solely on the receiver's implementation type. TooL is a pure object-oriented language that
The TooL language is strongly and statically typed in the sense that no operation will ever be invoked on an object that does not support it, i.e. errors like 'message not understood' cannot occur at run time.
Several conventional object models couple the implementation of an object with its type by unifying classes and types. In these models, an object of a certain class cannot be used in a context where another class is required if there is no inheritance relationship between these classes, even if both classes implement the same interface. TooL has adopted a more expressive type system based on conformance. Intuitively, an object conforms to a type when it supports at least the operations required by the type. That is, TooL views types as (unordered) sets of method signatures. The additional flexibility of conformance based typing is especially useful when integrating external services in distributed systems.
Consequently, following recent research results on subtyping and inheritance, the TooL type hierarchy (implicitly defined by the subtype relation) does not have to be equal to the class hierarchy (explicitly defined by inheritance declarations): class specialization (by inheritance) can lead to type generalization or even to incompatible types that are in no subtype relation at all.
In order to overcome some limitations of bounded parametric polymorphism, TooL captures certain forms of self-referencial similarity of object types by introducing a second relation on types orthogonal to the subtype relation: the matching relation '<*:' as it is implemented in the Emerald system. This is exactly F-Bounded Polymorphism.
TooL supports the clean separation of the interface specification of an object (the set of messages an external client can send to the object), and the implementation of an object (i.e. the corresponding method bodies to these messages). These two parts of an object are specified in the public and private parts of a class description, respectively. Additionally, in the private part any number of private methods can be specified; these methods are not considered part of the external protocol of the object. The only object which can legally apply these private methods is the object itself. The expressions where these methods can be used are restricted to (statically determinable) messages to the pseudo-variables self and super.
Similar to CLOS, TooL supports multiple inheritance by an (ordered) specification of multiple superclasses within a class description. Possible conflicts are resolved by a linearization of the inheritance tree performed by a topological sort on the superclass lattice. Inheriting from the same class more than once has no effect: TooL has no repeated inheritance as in Eiffel or C++.
A more detailed TooL language report is in preparation. However, you might take a glance at a recent snapshot of the TooL syntax definition.