Re: [Caml-list] Re: Improving OCaml's choice of type to display

[Jun Furuse <jun.furuse@gmail.com>]

I have quickly wrote a small patch against 3.11.1 for this feature, to
see what it would be like.

http://sites.google.com/a/furuse.info/jun/hacks/other-small-ocaml-patches

With this patch, path names are printed without opened modules in the
context. It also tries heuristic data type name simplification: if a
variant/record data type is an alias of another data type whose name
is shorter than the original, the printer uses the latter.

For example:

# open Hashtbl;;
# let tbl = Hashtbl.create 10;;
val tbl : ('_a, '_b) t = <abstr>      (* not Hashtbl.t, since Hashtbl is open *)

# type t = int;;
type t = int
# type long_name = int;;
type long_name = int
# (1 : t);;
- : t = 1                     (* t is the shorter than its original type int *)
# (1 : long_name);;
- : int = 1                   (* int is shorter name for long_name. t
is even shorter but not aliased unfortunatelly. *)

I warn you that the patch is very quickly written and not tested well. Enjoy!

Jun

On Fri, Oct 9, 2009 at 10:53 AM, Yaron Minsky <yminsky@gmail.com> wrote:
> 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
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>