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
>