[Camllist] Why are arithmetic functions not polymorph?

hermanns
 Brian Hurt
 Nicolas Cannasse
 David Monniaux
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:   (:) 
From:  David Monniaux <David.Monniaux@e...> 
Subject:  Re: [Camllist] Why are arithmetic functions not polymorph? 
On Fri, 23 May 2003, hermanns wrote: > I don't understand this, because comparison funtions ('<', '>', ...) > are polymorph. > So, where is the problem with arithmetic functions? There are several reasons. First, short of considering arithmetic types to be objects, there is no way to write types such as: forall ('a : arithmetic type), 'a > 'a > 'a. You may only write types of the form: forall 'a, 'a > 'a > 'a. This is not a problem since the polymorphic comparison function has the type: forall 'a, 'a > 'a > int. Polymorphic comparisons is a priori defined on all types; if used on functional objects, it may throw an exception. Second, it would be inefficient. Polymorphic comparison is implemented by traversing the memory data structures, using the runtime type information meant for the garbage collector. Note that if the compiler can figure at compile time that the type of the operands of <, <= etc..., it may generate some specialized version more efficient than calling the polymorphic comparison routine. In short, using a similar solution for +, , *, / would be a bad idea:  polymorphic comparisons are inefficient compared to comparisons on integers and IEEE floatingpoint numbers;  short of a significant change in the type system, +, , *, / would not refuse nonarithmetic operands, but would throw exceptions at runtime if applied to nonarithmetic arguments. SML has a kind of operator overloading, but I don't know the details. David Monniaux http://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France  To unsubscribe, mail camllistrequest@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/camlbugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners