From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 250C1BC37 for ; Sun, 11 Oct 2009 17:12:50 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoCABuT0UrRVd3DkGdsb2JhbACDAIxUgXGJCD8BAQEBCQkMBxMDqhiBOoUQiGUBAwMFhCgE X-IronPort-AV: E=Sophos;i="4.44,542,1249250400"; d="scan'208";a="38015849" Received: from mail-qy0-f195.google.com ([209.85.221.195]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Oct 2009 17:12:49 +0200 Received: by qyk33 with SMTP id 33so8111893qyk.29 for ; Sun, 11 Oct 2009 08:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=zAnIn3gK6DQARBh9A/O7cBr96wvKIFW7orDE0wTvAp0=; b=QrJKNNDPQE3Vtf+LWg0tGviE35hg9NnpxeLiVhR1O0mpvnzcIXehFiX1kuRHF8nA3O jEDjk77efO/4LQ7k0SpaB92qloujNLUgoCOh2rF7Pbzmxq44g7lRPba0qs7dYoXHT5Zp 3ck59LKQRR0sfJFBX9rGvqLkJrby/D3SgPAsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=xwUPufaQ4vjeS0/DG9I8/GIUDJzHZ2dDveqdWvkWGbSgEZKcoZj5ywRf9JB8YlOb7M IW0L+cYYNxHZDrY7lvuZgeh4rLFO9u8+XZiqFBWlP6Lx1BqOihhrVlbPzwfCj486tnMN 0qAP+9ttElpbNwq2FRBsfBvi+LJsJs/i0tmrw= Received: by 10.224.8.3 with SMTP id f3mr4147241qaf.147.1255273967193; Sun, 11 Oct 2009 08:12:47 -0700 (PDT) Received: from ?10.0.1.16? (user-0cevcqv.cable.mindspring.com [24.239.179.95]) by mx.google.com with ESMTPS id 26sm3911892qwa.11.2009.10.11.08.12.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Oct 2009 08:12:45 -0700 (PDT) References: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> <891bd3390910081853m5409c871y35495c6f16e180aa@mail.gmail.com> <5160b4200910110757y47ffad15v70434418cba61f26@mail.gmail.com> Message-Id: <62B782AA-1F44-4207-B037-5C6D1F6CBF50@gmail.com> From: Yaron Minsky To: Jun Furuse In-Reply-To: <5160b4200910110757y47ffad15v70434418cba61f26@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Subject: Re: [Caml-list] Re: Improving OCaml's choice of type to display Date: Sun, 11 Oct 2009 11:12:39 -0400 Cc: "caml-list@yquem.inria.fr" X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 ocaml's:01 yaron:01 minsky:01 furuse:01 furuse:01 hashtbl:01 hashtbl:01 val:01 abstr:01 yminsky:01 infix:01 infix:01 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 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 = (* 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 > 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 >> 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 = >>> # Float.of_string;; >>> - : string -> Core_extended.Std.Float.stringable = >>> >>> I'd be much happier if this was rendered in the following equally >>> correct >>> and more readable form: >>> >>> # Int.of_string;; >>> - : string -> Int.t = >>> # Float.of_string;; >>> - : string -> Float.t = >>> >>> Or even: >>> >>> # Int.of_string;; >>> - : string -> int = >>> # Float.of_string;; >>> - : string -> float = >>> >>> 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 >> >>