Interpretation versus compilation

In order to have a prototype of the Mathemagix language in a reasonable amount of time, it is important to be able to write an interpreter first. Depending on the language, it can be more or less hard to do this.

For instance, when the language allows for overloading, like Aldor does, then one needs an on-the-fly mechanism for typing ambiguous expressions. This can either be done by requiring each function application to be disambiguous, or by allowing for ambiguous values. In several cases, we found the first approach to be unsatisfactory (literals integer values are naturally ambiguous, access functions to a table are naturally ambiguous in Mathemagix (read-only or read-write access), etc.). The second approach has the disadvantage that one might have to propagate disambiguities and thereby delay the actual evaluation. Nevertheless, in Mathemagix, this could easily be done using continuations. However, the user should be aware of these potential changes in the order of evaluation.

Another problem is that certain type information can be expensive to obtain (find the right method in a heavily overloaded function) and very context sensitive (the import primitive in Aldor). In Mathemagix this problem is solved by (implemented in a global way) caching type resolutions and (not implemented) propagating this information to the outermost scope where it remains valid.