Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for <

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Carlos Pita <cpitaper@yahoo.com.ar>

> I would like to implement some number crunching inner loops for dsp
> stuff with ocaml. I'm a newcomer to the language with strong
> scheme/python background and trying to come into terms with type
> inference, parametric polymorphism and structural subtyping. One thing
> than I'm pretty fond of is the difference between floating point and
> integer basic mathematical operators. I guess the compiler is able to
> generate specific and more efficient code for each case without further
> analysis. But then I found out that comparison operators offer some kind
> of adhoc polymorphism in the guise of parametric one:
> 
> # (<);;
> - : 'a -> 'a -> bool = <fun>
> 
> Is there any reason for this apparently inconsistent design? Would the
> generality of < be against performance if for example, say, my critical
> inner loops check against a top limit value thousands of times per
> second?

The reason is that this operator comes handy for symbolic
computations, where you may want to compare lists or other data
structures. And contrary to addition, comparison makes sense for
almost any data structure.

Of course there is an overhead. But the compiler is clever enough to
remove this overhead when the types of arguments are statically known.
In particular this is true for floats.
If you're going to do number crunching, you must be careful of
using it only in situation where the types of the arguments are known,
i.e. not inside polymorphic functions. Typical examples of polymorphic
functions that will call the slow version of equality are List.mem and
List.assoc.

Cheers,

Jacques Garrigue