caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David Allsopp" <dra-news@metastack.com>
To: "'Vincent Aravantinos'" <vincent.aravantinos@gmail.com>,
	"'Damien Guichard'" <alphablock@orange.fr>
Cc: <caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] Improving OCaml's choice of type to display
Date: Fri, 9 Oct 2009 16:27:19 +0100	[thread overview]
Message-ID: <001b01ca48f4$fe9099f0$fbb1cdd0$@metastack.com> (raw)
In-Reply-To: <906B3DB3-5804-4C62-9044-EF5F3968AB4B@gmail.com>

> Le 9 oct. 09 à 16:18, Damien Guichard a écrit :
>
>
> Imagine my code is:
> 
>  type color = int
> 
>  let black : color = 0 
> 
> Then, following your proposition, evaluating black should give me
an int rather than a color because int is shorter and therefore nicer.

Hmm, I'd say that having OCaml respond "val black : int = 0" is indeed the
more useful answer (but not because int is shorter)... there are quite often
times where you get complex looking types (for good reason) which are in
fact aliases of much simpler types where it would (IMO) be much nicer for
OCaml to "call a spade a spade" and just tell you it's an int (Set.Make and
Map.Make being obvious cases[1]). Perhaps OCaml could make us both happy by
responding "val black : color = int = 0" (i.e. show the inferred and
possibly aliased type and also the principal base type, if it's different
from the inferred type)

The "unnecessary" complexity of the type names can also arise quite easily
if you're using with functors so need to present a particular type to
satisfy a signature - at which point having Foo.Bar.Other.Module.t (which is
in fact an int) may create irritatingly long type messages but the structure
being that way is probably hugely useful when it gets applied to
Magic.Make(Foo) elsewhere...


David


[1] Consider, somewhat obtusely, [let x : Map.Make(String).key = ""] (which
in real code is inferred rather more trivially from anything manipulating
sets and maps)


  reply	other threads:[~2009-10-09 15:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09  1:40 Yaron Minsky
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 [this message]
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='001b01ca48f4$fe9099f0$fbb1cdd0$@metastack.com' \
    --to=dra-news@metastack.com \
    --cc=alphablock@orange.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=vincent.aravantinos@gmail.com \
    /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).