Classical strongly typed systems

Among others, we have studied the type systems of Axiom/Aldor, C++, Scheme and Caml. Let us briefly describe some of our feelings about the positive and negative sides of these type systems.

Aldor

The Aldor language is based on categories or signatures. Genericity is achieved by explicitly declaring all methods which a generic type is allowed to use by means of a category. In order to use such a method it should be explicitly imported first. The advantages of this approach are

• The user is forced to cleanly modelize the appropriate categories and the compiler checks whether the user conforms to the desired specifications.
• The type checking during the compilation is extremely efficient, because only a scalar types and methods are visible, due to the import construct.

However, the first advantage also leads to several disadvantages concerning the flexibility of the type system:

• A routine which has been written for a given category, cannot easily be reused for a subcategory, even if the code would allow to do this.
• Minor variations of categories can lead to a wealth of categories which are difficult to master and organize.
• The user has to explicitly design categories and keep track of importations all the time, which leads to considerable administrative burden.

As a consequence, Aldor is mainly useful if the theory that one wishes to program is well-modelized beforehand. However, the rigidity of the type system can become a problem for large scale projects and especially research projects where models may have to be adapted as a function of time. Other disadvantages of Aldor is that is hard to write an interpreter for it, that the type inheritance system is very rigid and that it lacks of support for implicit conversions. The latter draw-backs could easily be removed though.

C++

A limited degree of genericity in C++ is achieved through the use of templates. The advantages of templates are their flexibility: not much type checking is done over the quantified variabled and their use requires no particular effort from the user. However, all possible types which are used during the execution have to be known at compile time, so that the user cannot use any real generic objects. Furthermore, templates do not behave nicely in combination with other dirty C++ “features” like the #include directive and the header-file mechanism.

Scheme

The Scheme language is nice because if its extreme simplicity, flexibility and the power of its control structures based on continuations. As many computer algebra languages (which are often based on Lisp), all type checking is done dynamically, at run-time. This has the advantage that an interpreter is extremely easy to write, but that too few type-knowledge is given to the compiler in order to produce really efficient code. Another disadvantage of the impossibility to define typed variables is that is non-trivial to integrate overloading and implicit type-conversion into the language.

Caml

The functional Caml language shares many of the advantages of the Scheme language, while providing a genuine type system. The Caml type system has the advantages that

• The type-checking can be done at compile-time, which made it possible to write a highly efficient compiler.
• The types of expressions can be determined automatically, so that the user does not need to care about the types in declarations.

In a sense, the second advantage is at the exact opposite of the rigid type system of Aldor: all necessary type information is determined from the code. However, this intelligence of Caml has the inconvenience that it may passes useful safety type checks. It also carries the disadvantage of Scheme that it is non-trivial to integrate overloading and implicit type-conversion.