caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jeremy Yallop <yallop@gmail.com>
To: Ben Millwood <bmillwood@janestreet.com>
Cc: Philippe Veber <philippe.veber@gmail.com>,
	 Abdallah Saffidine <abdallah.saffidine@gmail.com>,
	caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] How to use GADTs across modules in OCaml without raising warnings?
Date: Tue, 13 Oct 2015 10:45:27 +0100	[thread overview]
Message-ID: <CAAxsn=H0gF0ckKLDhAneDiLUdkeHq3f6fvda5LDqun5Kh+FRGg@mail.gmail.com> (raw)
In-Reply-To: <CA+MHO523ptj41cdDP0mHwy2inz4vJpaZeEt0vASagEs=mOhaSQ@mail.gmail.com>

On 13 October 2015 at 07:15, Ben Millwood <bmillwood@janestreet.com> wrote:
> I'll advance on others' advice by pointing out that if you say:
>
> type never = private [`never]
>
> then you neither "use up" a constructor name nor is it possible to write an
> expression with type never.

A nit: there are lots of *expressions* of type 'never', such as
'(assert false: never)'.  However, there are no (closed) *values* of
type 'never'.

> Unfortunately, the compiler still doesn't realise that, so it
> doesn't help you for pattern-matching.

The gadt-warnings branch, which is described here:

   GADTs and exhaustiveness: looking for the impossible
   Jacques Garrigue's and Jacques Le Normand
   ACM SIGPLAN Workshop on ML, September 2015
   http://www.mlworkshop.org/gadts-and-exhaustiveness-looking-for-the-impossible.pdf

includes better supports for "empty" types.  For example, here's a
definition of an empty type 'wrong':

   type 'a is_true = T: [`True] is_true
   type wrong = [`False] is_true

and here's a function definition which omits a case that you can
deduce is unmatchable when you know that 'wrong' is empty:

   let f : wrong option -> unit = fun None -> ()

The current OCaml compiler (4.02.3) issues a warning for 'f':

   Warning 8: this pattern-matching is not exhaustive.
   Here is an example of a value that is not matched:
   Some _

In contrast, the compiler in the gadt-warnings branch compiles 'f'
without complaint (and generates more efficient code, since there's no
need to inspect the argument).

Jeremy.

  reply	other threads:[~2015-10-13  9:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-13  5:27 Abdallah Saffidine
2015-10-13  6:06 ` Stefan Holdermans
2015-10-13  6:09 ` Philippe Veber
2015-10-13  6:15   ` Ben Millwood
2015-10-13  9:45     ` Jeremy Yallop [this message]
2015-10-14  2:13       ` Abdallah Saffidine
2015-10-13  6:10 ` Jacques Garrigue

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='CAAxsn=H0gF0ckKLDhAneDiLUdkeHq3f6fvda5LDqun5Kh+FRGg@mail.gmail.com' \
    --to=yallop@gmail.com \
    --cc=abdallah.saffidine@gmail.com \
    --cc=bmillwood@janestreet.com \
    --cc=caml-list@inria.fr \
    --cc=philippe.veber@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).