From: Abdallah Saffidine <abdallah.saffidine@gmail.com>
To: Jeremy Yallop <yallop@gmail.com>
Cc: Ben Millwood <bmillwood@janestreet.com>,
Philippe Veber <philippe.veber@gmail.com>,
caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] How to use GADTs across modules in OCaml without raising warnings?
Date: Wed, 14 Oct 2015 13:13:27 +1100 [thread overview]
Message-ID: <CALx9x4fysYC4hXC_RyQrjuCbYcgVdxZKoqpJxoTx0oH7SxtzKQ@mail.gmail.com> (raw)
In-Reply-To: <CAAxsn=H0gF0ckKLDhAneDiLUdkeHq3f6fvda5LDqun5Kh+FRGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
Dear all,
Thanks a lot for your help. Things are much clearer now.
Abdallah
2015-10-13 20:45 GMT+11:00 Jeremy Yallop <yallop@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.
>
[-- Attachment #2: Type: text/html, Size: 2677 bytes --]
next prev parent reply other threads:[~2015-10-14 2:13 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
2015-10-14 2:13 ` Abdallah Saffidine [this message]
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=CALx9x4fysYC4hXC_RyQrjuCbYcgVdxZKoqpJxoTx0oH7SxtzKQ@mail.gmail.com \
--to=abdallah.saffidine@gmail.com \
--cc=bmillwood@janestreet.com \
--cc=caml-list@inria.fr \
--cc=philippe.veber@gmail.com \
--cc=yallop@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