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