Among others, we have studied the type systems of Axiom/Aldor, C++, Scheme, OCaml and Haskell. Let us briefly describe some of our feelings about the positive and negative sides of these type systems. We refer to our overview of the Mathemagix type system for a more detailed discussion.

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 are that the type inheritance system is very rigid and that it lacks 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 discrete and parametric overloading into the language.

OCaml

The functional OCaml language shares many of the advantages of the Scheme language, while providing a genuine type system. The OCaml 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 OCaml has the inconvenience that potentially useful type safety double checks are being bypassed. It also carries the disadvantage that it is non-trivial to integrate discrete and parametric overloading.

Haskell

The Haskell language is similar to OCaml in various respects, but it comes with a lot of syntactic sugar which makes it relatively easy to define polymorphic types and routines. This is sometimes considered to be a typesafe substitute for C++-style overloading (“ad hoc polymorphism”). However, we disagree with this opinion, and believe that genuine overloading as implemented in Mathemagix is closer to classical mathematical notations.