]> And you can compete to come up with the most innocuous code that comes up with the longest type. Here's my current favorite: # open Option.Monad_infix;; # Map.find m 3 >>| fun x -> x + 1;; - : int Core.Std.Option.Monad_infix.monad = Some 4 Which of course could be rendered as: # open Option.Monad_infix;; # Map.find m 3 >>| fun x -> x + 1;; - : int option = Some 4 y On Thu, Oct 8, 2009 at 9:40 PM, Yaron Minsky <yminsky@gmail.com> wrote: > Anyone who plays around with the Core library that Jane Street just > released can see showcased a rather ugly detail of how Core's design > interacts with how OCaml displays types. Witness: > > # Int.of_string;; > - : string -> Core.Std.Int.stringable = <fun> > # Float.of_string;; > - : string -> Core_extended.Std.Float.stringable = <fun> > > I'd be much happier if this was rendered in the following equally correct > and more readable form: > > # Int.of_string;; > - : string -> Int.t = <fun> > # Float.of_string;; > - : string -> Float.t = <fun> > > Or even: > > # Int.of_string;; > - : string -> int = <fun> > # Float.of_string;; > - : string -> float = <fun> > > And this isn't just an issue in the top-level. The compiler also displays > types in the same difficult to read form. I'm wondering if anyone has some > thoughts as to what we can do to make the compiler make better choices > here. There are two issues to overcome: > > - Dropping the module name. I'd love to give the compiler the hint > that Core.Std. could be dropped from the prefix in a context where that > module is open. This is what's done with the pervasives module already, I > believe, so it seems like it should be doable here. > - Choosing shorter names. This one seems harder, but there are various > different possibilities for what type name to print out, and a reasonable > heuristic to use might be to pick the shortest one. Part of the reason > these issues come up is our use of standardized interface components (that's > where the "stringable" type name comes from). I suspect this one will be > hard to fix, sadly. > > Anyway, we'd be happy with any suggestions on how to improve matters. > > y >