> Le 9 oct. 09 à 16:18, Damien Guichard a écrit :
>
>
> Imagine my code is:
> 
>  type color = int
> 
>  let black : color = 0 
> 
> Then, following your proposition, evaluating black should give me
an int rather than a color because int is shorter and therefore nicer.

Hmm, I'd say that having OCaml respond "val black : int = 0" is indeed the
more useful answer (but not because int is shorter)... there are quite often
times where you get complex looking types (for good reason) which are in
fact aliases of much simpler types where it would (IMO) be much nicer for
OCaml to "call a spade a spade" and just tell you it's an int (Set.Make and
Map.Make being obvious cases[1]). Perhaps OCaml could make us both happy by
responding "val black : color = int = 0" (i.e. show the inferred and
possibly aliased type and also the principal base type, if it's different
from the inferred type)

The "unnecessary" complexity of the type names can also arise quite easily
if you're using with functors so need to present a particular type to
satisfy a signature - at which point having Foo.Bar.Other.Module.t (which is
in fact an int) may create irritatingly long type messages but the structure
being that way is probably hugely useful when it gets applied to
Magic.Make(Foo) elsewhere...


David


[1] Consider, somewhat obtusely, [let x : Map.Make(String).key = ""] (which
in real code is inferred rather more trivially from anything manipulating
sets and maps)