caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yaron Minsky <yminsky@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Improving OCaml's choice of type to display
Date: Thu, 8 Oct 2009 21:40:26 -0400	[thread overview]
Message-ID: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3115 bytes --]

             reply	other threads:[~2009-10-09  1:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09  1:40 Yaron Minsky [this message]
2009-10-09  1:53 ` Yaron Minsky
2009-10-11 14:57   ` [Caml-list] " Jun Furuse
2009-10-11 15:12     ` Yaron Minsky
2009-10-11 15:24       ` Jun Furuse
2009-10-11 19:57         ` Gilles Pirio
2009-10-11 21:17           ` [Caml-list] " Damien Guichard
2009-10-11 21:46             ` Gilles Pirio
2009-10-11 22:16               ` Lukasz Stafiniak
2009-10-09  7:33 ` Andrej Bauer
2009-10-09  9:58   ` Yaron Minsky
2009-10-09 10:54     ` Alp Mestan
2009-10-09 11:15       ` Yaron Minsky
2009-10-09 14:18     ` Damien Guichard
2009-10-09 14:44       ` Vincent Aravantinos
2009-10-09 15:27         ` David Allsopp
2009-10-09 16:52       ` Yaron Minsky
2009-10-09 18:23         ` Damien Guichard
2009-10-09 18:14   ` Stephen Weeks
2009-10-10 15:08     ` Damien Guichard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com \
    --to=yminsky@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).