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

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

I have not tested it well but it counts dots and should try to find
the minimal one.

A problem I have found so far is that it prints something confusing, ex.

module M = struct type t end
module N = struct type t end
open M
open N

let _ = ( 1 : M.t )

>> Error: This expression has type int but an expression was expected of type t    (which t ?!?!?)

If there are types M.t and N.t and the both of M and N are opened,
these types are printed just "t". This can be avoided by testing the
result name "t" against the current typing envrionment to see it
really means the original type "M.t". This requires more coding but
the weekend has ended in the far east already :-)   (It's 0:24 Monday
now.)

Jun

On Mon, Oct 12, 2009 at 12:12 AM, Yaron Minsky <yminsky@gmail.com> wrote:
> 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
>>>
>>>
>