]> > 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)