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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 01CC9BBAF for ; Fri, 9 Oct 2009 03:40:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAB0xzkrRVdSskWdsb2JhbACCJi+Xbz8BAQEBCQsKBxMDrgkKgTGPTgEDAwWEJQSIAw X-IronPort-AV: E=Sophos;i="4.44,528,1249250400"; d="scan'208";a="34560114" Received: from mail-vw0-f172.google.com ([209.85.212.172]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Oct 2009 03:40:27 +0200 Received: by vws2 with SMTP id 2so243599vws.15 for ; Thu, 08 Oct 2009 18:40:26 -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:date:message-id :subject:from:to:content-type; bh=TQOH9XYXBBrrFqrgEIQorU2ytJgeJWp+UW3pB+FWmS4=; b=X4ONdImOi1hkIiR8FjRwbPAVVK+ytJ5uBlb8DzxsoK+VdIW68mLUVgaCybQxZgmxYw EAOMh+5s122VVOVTd6Me9zlqhtR6/jL/EjaXzc5ELornSZwNXlkXuPrMApQMS6NOLv33 KSPHXtJmV45HD5XHPw0qh/EM6aA3gtXkpslpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=p0IzkWw3KhSLj/pmitS/aQJeaHYGdP+94G3ZBQjiBOKK+NPKROUJyTDmxCXNQggx3G 5/6wYrBoRmmvm7LRmZjzFp90s6Dh2N2woRRPKZf0ydMJXTH2H9xPgSkNpoDcd8nE5pFo HRTctPyk1bjnVtGPERpTksNOq/NdsiP6luyN0= MIME-Version: 1.0 Received: by 10.220.42.11 with SMTP id q11mr3163504vce.88.1255052426054; Thu, 08 Oct 2009 18:40:26 -0700 (PDT) Reply-To: yminsky@gmail.com Date: Thu, 8 Oct 2009 21:40:26 -0400 Message-ID: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> Subject: Improving OCaml's choice of type to display From: Yaron Minsky To: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016364c7032078cd1047576aab8 X-Spam: no; 0.00; ocaml's:01 yaron:01 minsky:01 yminsky:01 interacts:01 ocaml:01 compiler:01 compiler:01 pervasives:01 doable:01 interacts:01 ocaml:01 pervasives:01 doable:01 sans-serif:98 --0016364c7032078cd1047576aab8 Content-Type: text/plain; charset=ISO-8859-1 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 --0016364c7032078cd1047576aab8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anyone who plays around with the Core library that Jane Street just release= d can see showcased a rather ugly detail of how Core's design interacts= with how OCaml displays 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
 --0016364c7032078cd1047576aab8--