caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: bluestorm <bluestorm.dylc@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] GADT constructor syntax
Date: Mon, 6 Dec 2010 09:21:39 +0900	[thread overview]
Message-ID: <FCC02BEF-BC47-42ED-95E1-DC0D898766EE@gmail.com> (raw)
In-Reply-To: <AANLkTimbhypTd6Y2v35SdV4qkH8tGtquc6Nt+N45oK4+@mail.gmail.com>

On 2010/12/05, at 17:35, bluestorm wrote:

> I'm not sure I see the point of this long discussion between Lukasz and Jacques.
> 
> It seems everybody agree that it is a good idea to explicitely quantify the constructor-specific type variables.
> 
> The question Jacques raised is wether, when we write (| Foo of 'a . S : T) or (| Foo : 'a . S -> T), the 'a is quantified on S only, or on both S and T. 
> 
> It think we all agree that, for semantical reasons, quantification should be scoped over both S and T. However, the (of S : T) syntax does not make it very obvious, and this should be rightfully considered as a defect of this syntax.
> 
> I'm under the impression that your intense debate is about the edge case where :
> 1. we don't use explicit quantification of constructor-specific variables
> 2. we reuse the type parameter variables in the type of a GADT constructor (so they're implicitly shadowed by the implicit quantifications, or maybe not)
> 
> If we reject possibly 1. (and ask for explicit quantification), all is well. If you want to consider option 1., then I think the edge case 2. is evil and shoud result in a warning.

Actually I'm not sure that fully explicit quantification is necessary, or even desirable.
The reason is that the gadt extension introduces actually two kinds of case-specific
type variables: universals and existentials.

Namely, in the type

  type _ term =
      Int : int -> int term
    | Bool : bool -> bool term
    | Lam : ('a -> 'b) -> ('a -> 'b) term
    | App : ('a -> 'b) * 'a -> 'b term

the type variables 'a and 'b in Lam are universals, but
in App only 'b is universal, while 'a is existential.

Personally, I would prefer this to be written:

  type _ term =
      Int of int : int term
    | Bool of bool : bool term
    | Lam of ('a -> 'b) : ('a -> 'b) term
    | App of 'a. ('a -> 'b) * 'a : 'b term

That is, use a syntax close to the current ocaml one, which makes
easy to quantify clearly existential variables, so that they cannot
be confused with universal ones. If we use the arrow syntax,
the natural scope for quantification includes the return type, which
is incorrect for existential types. And using the "of" syntax, it is hard
to quantify type variables appearing in the return type, so I think
this is better to leave the universals implicit.

Considering the definition

  type 'a t = Foo of 'a : 'b t

I think that is should either unify 'a and 'b, being in practice
equivalent to "type 'a t = Foo of 'a", or flag an error because 'a is not
available in this branch. I might actually prefer the unification approach,
because this conforms to the intuition that the scope of 'a is the whole
type definition, but maybe people can come to understand that an
explicit return type overrides this.

Jacques Garrigue

  reply	other threads:[~2010-12-06  0:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-04 19:25 Jacques Le Normand
2010-12-04 19:36 ` [Caml-list] " gasche
2010-12-04 19:39 ` Basile Starynkevitch
2010-12-04 19:41 ` Lukasz Stafiniak
2010-12-04 20:14   ` Jacques Le Normand
2010-12-04 20:22     ` Lukasz Stafiniak
2010-12-04 20:54       ` Jacques Le Normand
2010-12-04 21:00         ` Lukasz Stafiniak
2010-12-04 21:06           ` Jacques Le Normand
2010-12-05  8:10             ` Lukasz Stafiniak
2010-12-05  8:16               ` Lukasz Stafiniak
2010-12-05  8:25               ` Lukasz Stafiniak
2010-12-05  8:35                 ` bluestorm
2010-12-06  0:21                   ` Jacques Garrigue [this message]
     [not found] <1245532236.1431213.1291490707868.JavaMail.root@zmbs3.inria.fr>
2010-12-06  9:11 ` Daniel de Rauglaudre

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=FCC02BEF-BC47-42ED-95E1-DC0D898766EE@gmail.com \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /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).