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>>>
>>>
>
_______________________________________________
Caml-list
mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-listArchives:
http://caml.inria.frBeginner's list:
http://groups.yahoo.com/group/ocaml_beginnersBug
reports:
http://caml.inria.fr/bin/caml-bugs