Version française
Home     About     Download     Resources     Contact us    
Browse thread
Improving OCaml's choice of type to display
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Yaron Minsky <yminsky@g...>
Subject: Improving OCaml's choice of type to display
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