Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Why are arithmetic functions not polymorph?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: brogoff@s...
Subject: Re: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)
On Sat, 7 Jun 2003, wrote:
> Yes, in this case, it is easy to tell that there is only one
> applicable typing for plus one two, that is plus : float -> float -> float.
> But in general, nubmer of type case combinations may increase quite
> easily and searching applicable typing from them becomes quite inefficient.
> Moreover, when we have recursive generic values, the search space may
> be infinite! Therefore, we must restrict the search space of type case
> combinations in some manner (otherwise, typing may never terminates). 
> The restriciton in the G'Caml implementation is quite simple, 
> therefore you may feel some inconvenience: the type of plus one two 
> is not inferred automatically, for example.

    I understand the pragmatics. If it turns out that this is painful in 
practice for cases like linear algebra or numerics libraries where the 
generic values are not recursive, I hope that a less restrictive rule can be 
adopted. I don't think that the hacks used by other languages which have 
types which throw the type checker into a loop (setting some iteration limit) 
are so bad, and I think they can be applied here. 

    Right now we don't have any significant practice to go on, so I think the 
conservative rule is OK, since, as you point out, it is simple. It's a bit 
weird that the example I posted works if the order is switched in the 
declaration of "plus". 

-- Brian

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: