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>
Cc: "'Jacques Garrigue'" <garrigue@math.nagoya-u.ac.jp>,
	<caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] Private types
Date: Sat, 1 Nov 2008 20:18:49 -0000	[thread overview]
Message-ID: <8E52E728B9D54B9AAF6219C7518248A7@countertenor> (raw)
In-Reply-To: <490CAE8A.8020408@gmail.com>

Edgar Friendly wrote:
> David Allsopp wrote:
>
> > 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!
> 
> Okay, you claim we shouldn't automatically open polymorphic variants.  I
> don't see why auto->ing polymorphic types is really a problem.  If the
> later code (receiving the returned value) can't handle the [> ] type,
> that type error will stop things (although it won't point out where the
> [> ] came from).  This seems one case where the compiler can easily DWIM
> the correct result.

I agree that the error will still show up somewhere if there is an error -
but remember that a closed polymorphic variant type required an annotation
in the first place (in this case, the type [t] and the explicit type
annotation to use it)... so having made the explicit choice to declare the
type closed (which you either do to declare module interfaces or to try to
trap errors) the last thing (I'd say!) you want is the compiler trying to
open them back up on every unification failure!


David


  reply	other threads:[~2008-11-01 20:19 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
2008-11-01 19:31           ` Edgar Friendly
2008-11-01 20:18             ` David Allsopp [this message]
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=8E52E728B9D54B9AAF6219C7518248A7@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).