The current Mathemagix type system

Since 2006, the structure of Mathemagix has been heavily reorganized and a new interpreter has been written. The type system of the new interpreter is a bit weaker than before in this respect that we no longer have template types. In the future, we wish to let the current type system evolve gradually towards the ultimate Mathemagix type system, which combines all good features of the past, present and future.

The current type system also comes with a few improvements. First of all, it is now possible to define automatic converters. Such converters can be combined according to transtivity properties which may be declared by the user. Secondly, the new type system provides a generic type Generic, together with an automatic converter T -> Generic for any type T.

The mixture of a generic type with conventional strongly typed system raises some subtle, but interesting, questions:

1. One has to be careful with automatic conversions: using converters T -> Generic and Generic -> Vector Generic, and similarly for Matrix Generic, Series Generic, etc., any type T can be converted into Vector Generic. In particular, when implementing operations on Vector Generic, one should avoid conversions of the scalars to Vector Generic, which may cause infinite loops.

   Currently, the above problem is solved by attaching penalties to converters (and penalties are combined using max rather than +). The converter Generic -> Vector Generic is used only if all other methods fail. However, we are generally not in favour of systems which are based on priorities. We intend to invent something cleaner in the future.

2. One of the reasons behind having a Generic type is to gracefully combine a high level user interface with a powerful programming language. However, these two objectives sometimes conflict. For instance, consider the example 2*(3/2); what should the return type be? The end-user sees 3 and will assume the result to be an Integer. However, from the programming point of view, returning a Rational makes it possible to design more systematic algorithms.

   Our current view on the above problem is to allow for both possibilities: programmers may use a strongly typed language in which 2*(3/2) will explicitly be considered to be a Rational. End-users rather rely on the Generic type and printing 2*(3/2) will imply an automatic conversion Rational -> Generic, which may actually simplify the rational into an integer. This mechanism has not been implemented and tested yet, but we hope to do this sometime soon.

3. When interfacing Mathemagix with other systems which also provide generic types, it may be necessary to implement type equivalences between different types of generic objects. The current automatic conversion facility already makes it possible to define such type equivalences for ordinary types. More research has to be done in order to extend these priciples to generic types (in particular, because of the penalty system).