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.7 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 2BE62BC37 for ; Sun, 11 Oct 2009 17:24:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDAKuV0UpKfVwaimdsb2JhbACDAIxUgXGJCD8BAQEKCQwHEQWqHIE6hQ+IZQEDAwWEKASCPA X-IronPort-AV: E=Sophos;i="4.44,542,1249250400"; d="scan'208";a="34692362" Received: from qw-out-2122.google.com ([74.125.92.26]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Oct 2009 17:24:43 +0200 Received: by qw-out-2122.google.com with SMTP id 5so1027619qwd.15 for ; Sun, 11 Oct 2009 08:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6Z6/RvoqK98gOQhQfyKh7FCDOIA0HSXGQ7FPsiIaEGc=; b=fDb1v1PunxtqKn+0pFM45o9+FhtxmJEs64EKtp5KF3K8RXp0DlZeL8Cy1rL3Qo4TnW f+SwCG2F/LRewpWBTFvhhJWBgETF7rsSBN+dS2D+jTUM/juuVXsWcw+/6IiAyNYlwlpB XzauIFKM/Uq27odYPOZf5gqgDdvrmrHee81T0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q+AXNSxmsAd3Uw7J7P7AyF0b8705/z023PXPWs3l+OWHefEQV1Vq/OeNMUdBiLVO+U pBC1cmaYRFs/o+A5/Z5SeX+J4cPJerzwhaoKCzSNFDnD+/RJuapdcUlt87NnarMZz4Td iD+WWRkcoopWprznxD7mg8Vb2PelyRQSEMIQ4= MIME-Version: 1.0 Received: by 10.229.118.6 with SMTP id t6mr2234038qcq.39.1255274681529; Sun, 11 Oct 2009 08:24:41 -0700 (PDT) In-Reply-To: <62B782AA-1F44-4207-B037-5C6D1F6CBF50@gmail.com> References: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> <891bd3390910081853m5409c871y35495c6f16e180aa@mail.gmail.com> <5160b4200910110757y47ffad15v70434418cba61f26@mail.gmail.com> <62B782AA-1F44-4207-B037-5C6D1F6CBF50@gmail.com> Date: Mon, 12 Oct 2009 00:24:41 +0900 Message-ID: <5160b4200910110824q7998f43ao3d00e94ba7e74b2b@mail.gmail.com> Subject: Re: [Caml-list] Re: Improving OCaml's choice of type to display From: Jun Furuse To: Yaron Minsky Cc: "caml-list@yquem.inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocaml's:01 furuse:01 furuse:01 struct:01 struct:01 avoided:01 yaron:01 minsky:01 yminsky:01 yaron:01 minsky:01 hashtbl:01 hashtbl:01 val:01 abstr:01 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 =3D struct type t end module N =3D struct type t end open M open N let _ =3D ( 1 : M.t ) >> Error: This expression has type int but an expression was expected of ty= pe 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 wrote: > Cool! =A0That was quick. > > Does this patch also implement stephen's fewest-number-of-dots heuristic?= =A0I > 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-patche= s >> >> 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 =3D Hashtbl.create 10;; >> val tbl : ('_a, '_b) t =3D =A0 =A0 =A0(* not Hashtbl.t, since Ha= shtbl is >> open *) >> >> # type t =3D int;; >> type t =3D int >> # type long_name =3D int;; >> type long_name =3D int >> # (1 : t);; >> - : t =3D 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (* t is the shorter = than its original type >> int *) >> # (1 : long_name);; >> - : int =3D 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (* 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. =A0Here's my current favorite: >>> >>> # open Option.Monad_infix;; >>> # Map.find m 3 >>| fun x -> x + 1;; >>> - : int Core.Std.Option.Monad_infix.monad =3D Some 4 >>> >>> Which of course could be rendered as: >>> >>> # open Option.Monad_infix;; >>> # Map.find m 3 >>| fun x -> x + 1;; >>> - : int option =3D 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. =A0Witness: >>>> >>>> # Int.of_string;; >>>> - : string -> Core.Std.Int.stringable =3D >>>> # Float.of_string;; >>>> - : string -> Core_extended.Std.Float.stringable =3D >>>> >>>> I'd be much happier if this was rendered in the following equally >>>> correct >>>> and more readable form: >>>> >>>> # Int.of_string;; >>>> - : string -> Int.t =3D >>>> # Float.of_string;; >>>> - : string -> Float.t =3D >>>> >>>> Or even: >>>> >>>> # Int.of_string;; >>>> - : string -> int =3D >>>> # Float.of_string;; >>>> - : string -> float =3D >>>> >>>> And this isn't just an issue in the top-level. The compiler also >>>> displays >>>> types in the same difficult to read form. =A0I'm wondering if anyone h= as >>>> some >>>> thoughts as to what we can do to make the compiler make better choices >>>> here. =A0There are two issues to overcome: >>>> >>>> Dropping the module name. =A0I'd love to give the compiler the hint th= at >>>> Core.Std. could be dropped from the prefix in a context where that >>>> module is >>>> open. =A0This is what's done with the pervasives module already, I >>>> believe, so >>>> it seems like it should be doable here. >>>> Choosing shorter names. =A0This one seems harder, but there are variou= s >>>> different possibilities for what type name to print out, and a >>>> reasonable >>>> heuristic to use might be to pick the shortest one. =A0Part of the rea= son >>>> these issues come up is our use of standardized interface components >>>> (that's >>>> where the "stringable" type name comes from). =A0I suspect this one wi= ll >>>> 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 >>> >>> >