caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David Allsopp" <dra-news@metastack.com>
To: "'Edgar Friendly'" <thelema314@gmail.com>,
	"'Jacques Garrigue'" <garrigue@math.nagoya-u.ac.jp>
Cc: <caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] Private types
Date: Sat, 1 Nov 2008 09:19:56 +0100	[thread overview]
Message-ID: <6788D960DAEA460EABA915DEA52D5CA2@countertenor> (raw)
In-Reply-To: <490BB657.5050301@gmail.com>

Edgar Friendly wrote:
> Jacques Garrigue wrote:
>
> > Your intuition is correct that it would theoretically be possible to
> > try subtyping in place of unification in some cases. The trouble is
> > that thoses cases are not easy to specify (so that it would be hard
> > for the programmer to known when he can remove a coercion), 
>
> Does the compiler really get any information from an explicit cast that
> it can't figure out already?  I can't come up with any example.

Polymorphic variants. Consider:

type t = [ `A of int ]

let f (x : t) =
  let `A n = x
  in
    if n mod 2 = 0
    then (x : t :> [> t ])
    else `B (2 * n)

Without the full coercion for x you'll get a type error because the type
checker infers that the type of the [if] expression is [t] from the [then]
branch and then fails to unify [> `B of int ] with [t] unless the type of
[x] is first coerced to [> t ]. If the compiler were to try (x : t : [> t ])
in all those instances I think that would render polymorphic variants pretty
unusable ... the type checker needs to know that you meant to do that or
everything will unify!

> > So the current approach is to completely separate subtyping and type
> > inference, and require coercions everywhere subtyping is needed.
> > 
> Would it be particularly difficult to, in the cases where type [x] is
> found but type [y] is expected, to try a (foo : x :> y) cast?

+1! With reference my previous comment that "the type checker needs to know
if you meant that", there's still the option of using fully abstract types
if you wanted to avoid this kind of automatic coercion and have, say,
positive integers totally distinct from all integers without an explicit
cast.

All said, I do see Jacques point of wanting to keep coercion and type
inference totally separate... though perhaps if coercions were only tried
during unification if at least one of the types in question is private that
would maintain a certain level of predictability about when they're used
automatically?


David


  reply	other threads:[~2008-11-01  8:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 20:18 David Allsopp
2008-10-30 20:33 ` [Caml-list] " Daniel Bünzli
2008-10-30 21:54   ` David Allsopp
2008-10-31  0:08     ` Jacques Garrigue
2008-10-31 14:05       ` Dario Teixeira
2008-11-01  9:52         ` Jacques Garrigue
2008-11-01  1:52       ` Edgar Friendly
2008-11-01  8:19         ` David Allsopp [this message]
2008-11-01 19:31           ` Edgar Friendly
2008-11-01 20:18             ` David Allsopp
2008-11-02 14:53               ` Edgar Friendly
2008-11-01 10:00         ` Jacques Garrigue
2008-11-01 19:41           ` Edgar Friendly
2008-11-01 13:01         ` Rémi Vanicat
2008-11-01 13:30           ` [Caml-list] " Edgar Friendly
2008-10-30 21:47 ` [Caml-list] " Jérémie Dimino
  -- strict thread matches above, loose matches on Subject: below --
2004-05-01 19:51 [Caml-list] Reading a large text file Alain.Frisch
2004-05-01 20:40 ` skaller
2004-05-01 21:11   ` [Caml-list] Private types skaller

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=6788D960DAEA460EABA915DEA52D5CA2@countertenor \
    --to=dra-news@metastack.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    --cc=thelema314@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).