caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Petter A. Urkedal" <paurkedal@gmail.com>
To: Markus Mottl <markus.mottl@gmail.com>
Cc: OCaml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Covariant GADTs
Date: Sun, 18 Sep 2016 10:17:36 +0200	[thread overview]
Message-ID: <CALa9pHQ7366ZY7T6f8UT23LjcqUrbwxyoZwYvNxaL+aGx83mfg@mail.gmail.com> (raw)
In-Reply-To: <CAP_800oyYHOz6TPkBWZ2oyBW0zC3r5veQCV5Gd32w7ZhO9DK=A@mail.gmail.com>

Hi Markus,

On 17 September 2016 at 19:38, Markus Mottl <markus.mottl@gmail.com> wrote:
> Hi,
>
> GADTs currently do not allow for variance annotations so I wondered
> whether there are any workarounds for what I want:
>
> -----
> type +_ t =
>   | Z : [ `z ] t
>   | S : [ `z | `s ] t -> [ `s ] t
>
> let get_next (s : [ `s ] t) =
>   match s with
>   | S next -> next
> -----
>
> The above compiles without the variance annotation, but then you
> cannot express "S Z", because there is no way to coerce Z to be of
> type [`z | `s] t.
>
> Another approach I tried is the following:
>
> -----
> type _ t =
>   | Z : [ `z ] t
>   | S : [< `z | `s ] t -> [ `s ] t
>
> let get_next (s : [ `s ] t) : [< `z | `s ] t =
>   match s with
>   | S next -> next
> -----
>
> The above gives the confusing error:
>
> -----
> Error: This expression has type [< `s | `z ] t
>        but an expression was expected of type [< `s | `z ] t
>        The type constructor $S would escape its scope
> -----
>
> There are apparently two type variables associated with [< `s | `z ]
> t: the locally existential one introduced by matching the GADT, and
> the one in the type restriction of the function, but the compiler
> cannot figure out that these can be safely unified.  There is
> currently no way of specifying locally abstract types that have type
> constraints, which could possibly also help here.

In this case, you can supply the needed type information to `get_next`
with structural type matching:

  type _ t = Z : [`z] t | S : 'a t -> [`s of 'a] t
  let get_next : [`s of 'a] t -> 'a t = function S next -> next

This gives you a richer type which also allows defining get_next_pair, etc.

> Are there workarounds to achieve the above?  Are there any plans to
> add variance annotations for GADTs?

I had a similar problem myself and found a paper [1] explaining the
issue and a possible solution.  Haven't really studied it, but as I
understand the issue is that the current GADTs only introduce type
equality, which is too strict to verify variance.  What is needed is
more like (my ASCIIfication)

  type +'a t =
    | Z when 'a >= [`z]
    | S when 'a >= [`s] of [< `z | `s] t

allowing 'a in each case to be a supertype rather than equal to the
specified type.  In that spirit, I tried

  type +_ t =
    | Z : [> `z] t
    | S : [< `s | `z] t -> [> `s] t;;

but that does not check for variance either.

Best,
Petter

[1] https://arxiv.org/abs/1301.2903

  reply	other threads:[~2016-09-18  8:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-17 17:38 Markus Mottl
2016-09-18  8:17 ` Petter A. Urkedal [this message]
2016-09-19  1:52   ` Markus Mottl
2016-09-19  8:58     ` octachron
2016-09-19 10:18       ` Mikhail Mandrykin
2016-09-19 13:37         ` Mikhail Mandrykin
2016-09-19 14:46         ` Markus Mottl
2016-09-19 14:53           ` Mikhail Mandrykin
2016-09-19 15:03             ` Markus Mottl
2016-09-20 21:07               ` Markus Mottl
2016-09-21 10:11                 ` Lukasz Stafiniak
2016-09-21 10:14                   ` Lukasz Stafiniak
2016-09-21 17:04                     ` Markus Mottl
2016-09-21 21:40                       ` Gabriel Scherer
2016-09-22  0:39                         ` Markus Mottl
2016-09-24  5:09                           ` Yaron Minsky
2016-10-04 10:33                 ` Jacques Garrigue
2016-09-19 14:39       ` Markus Mottl
2016-09-19 10:05     ` Goswin von Brederlow

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=CALa9pHQ7366ZY7T6f8UT23LjcqUrbwxyoZwYvNxaL+aGx83mfg@mail.gmail.com \
    --to=paurkedal@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=markus.mottl@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).