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=2.1 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 870F4BBAF for ; Fri, 9 Oct 2009 03:53:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowBAJc0zkrRVdSskWdsb2JhbACCJy6Xbz8BAQEBCQsKBxMDrg4KgTGPTQEDAwWEJQSIAw X-IronPort-AV: E=Sophos;i="4.44,529,1249250400"; d="scan'208";a="35976189" Received: from mail-vw0-f172.google.com ([209.85.212.172]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Oct 2009 03:53:04 +0200 Received: by vws2 with SMTP id 2so247565vws.15 for ; Thu, 08 Oct 2009 18:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=c4FaXRmx7bbrCmJppOq4Q8v5VXu1fOFC6IS5c56d5qg=; b=L8Kd3Lcz0RHIYH1/23fyPPnn4KqPXfVHokH2G1jWhJag33cjBgOFCfw8BKsOmAZAHC xlmQWYQ4nVGZbWkaFKfNH/epkgYYE9MZc06bbrg2amoK/jTpzWAu5zCnlX1pL000WCjx nhGCr9b3zQSbJH5a8kJfpZdOc1i6DhjoRVqDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=D6lX2tNjf0ag7dUuGmMV43ExzWaBm1ciEOxvQ1ovXGpzWdJLEcHJTfkU7LJ86etQA3 MTHLrZvlZnWoLCmXVKoctaeMAtG1doVvqwiFA8grltxD+TQ+86nUKavBDCZjElShDaWg s4XBsrDZnHt5ZnA7VLwX0OvJJXXK23zqtiKRk= MIME-Version: 1.0 Received: by 10.220.42.11 with SMTP id q11mr3167969vce.88.1255053183045; Thu, 08 Oct 2009 18:53:03 -0700 (PDT) Reply-To: yminsky@gmail.com In-Reply-To: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> References: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> Date: Thu, 8 Oct 2009 21:53:03 -0400 Message-ID: <891bd3390910081853m5409c871y35495c6f16e180aa@mail.gmail.com> Subject: Re: Improving OCaml's choice of type to display From: Yaron Minsky To: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016364c7032264f11047576d7bb X-Spam: no; 0.00; ocaml's:01 yaron:01 minsky:01 yminsky:01 infix:01 infix:01 yaron:01 minsky:01 yminsky:01 interacts:01 ocaml:01 compiler:01 compiler:01 pervasives:01 doable:01 --0016364c7032264f11047576d7bb Content-Type: text/plain; charset=ISO-8859-1 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 > --0016364c7032264f11047576d7bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And you can compete to come up with the most innocuous code that comes up w= ith the longest type.=A0 Here's my current favorite:

# open Option.Monad_infix;;=
# Map.find m 3 >>= | fun x -> x + 1;;
- : int Core.Std.Opt= ion.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 <yminsky@gmail.com> wrote:
Anyone who plays = around with the Core library that Jane Street just released can see showcas= ed a rather ugly detail of how Core's design interacts with how OCaml d= isplays types.=A0 Witness:

# Int.of_string;;
- : string -> Core.S= td.Int.stringable =3D <fun>
# Float.= of_string;;
- : string -> Core_e= xtended.Std.Float.stringable =3D <fun>

I'd be much = happier if this was rendered in the following equally correct and more read= able form:

# Int.of_string;;
- : string -> Int.t = =3D <fun>
# Float.of_string;;
- : string -> Float.= t =3D <fun>

Or even:

# Int.of_string;;
- : string -> int = =3D <fun>
# Float.of_string;;
- : string -> float = =3D <fun>

And= this isn't just an issue in the top-level. The compiler also displays = types in the same difficult to read form.=A0 I'm wondering if anyone ha= s some thoughts as to what we can do to make the compiler make better choic= es here.=A0 There are two issues to overcome:
  • Dropping the modul= e name.=A0 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.=A0 This = is what's done with the pervasives module already, I believe, so it see= ms like it should be doable here.
  • Choosing shorter names.=A0 Th= is 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.=A0 Part of the reason these issues come up is our use of= standardized interface components (that's where the "stringable&q= uot; type name comes from).=A0 I suspect this one will be hard to fix, sadl= y.
Anyway, we'd be happy wi= th any suggestions on how to improve matters.

y

--0016364c7032264f11047576d7bb--