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 --]
next 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