]> Cool! That was quick. Does this patch also implement stephen's fewest-number-of-dots heuristic? I was thinking one nice approach would be fewest-number-of- dots with ties broken by length of final identifier. Y Yaron Minsky On Oct 11, 2009, at 10:57 AM, Jun Furuse <jun.furuse@gmail.com> wrote: > 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 >> >>