Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: Ivan Gotovchits <ivg@ieee.org>, caml-list@inria.fr
Subject: Re: [Caml-list] phantom types and identity function
Date: Tue, 27 Nov 2012 16:59:43 +0100	[thread overview]
Message-ID: <CAPFanBFbY8drGNzwy8y6jOaFe=6oSs26PjtcWFMuntcTv8+eCQ@mail.gmail.com> (raw)
In-Reply-To: <1F656500-76AC-482F-BA08-A9BB8250D904@math.nagoya-u.ac.jp>

I have been a bit confused by this discussion, and found the relevant
part of the manual that may enlighten other list readers:

The OCaml Language, Type and exception definitions
  http://caml.inria.fr/pub/docs/manual-ocaml/manual016.html#toc54

  "If the type has either a representation or an equation, and the
  parameter is free (i.e. not bound via a type constraint to
  a constructed type), its variance constraint is checked but
  subtyping etc. will use the inferred variance of the parameter,
  which may be better; otherwise (i.e. for abstract types or
  non-free parameters), the variance must be given explicitly, and the
  parameter is invariant if no variance was given."


Note that this would not be needed if we had an explicit way to
express the variance of invariant (the variable appears in both
positive and negative positions) and irrelevant (the variable doesn't
appear except in irrelevant positions) explicitly. We could then
write, say:

  type 0'a t = {x : int} constraint 'a = [< `A | `B ]

The absence of such a variance marker means that some OCaml code is
hard to abstract through a module boundary: in presence of the
explicit definition, the type-checker will accept to subtype between
any instances of the type (by simple expansion), but if you abstract
over its definition you cannot express this property anymore. Your
workaround corresponds to statically expressing this irrelevance
through an exported equation, but there are (arguably somewhat
unnatural) scenarios where this isn't convenient.

On Tue, Nov 27, 2012 at 3:08 PM, Jacques Garrigue
<garrigue@math.nagoya-u.ac.jp> wrote:
>
> On 2012/11/27, at 20:00, Ivan Gotovchits <ivg@ieee.org> wrote:
>
> >
> > Hello,
> >
> > These simple signature
> >
> >   module type T = sig
> >       type 'a t constraint 'a = [< `A | `B ]
> >       val init: [`A] t
> >       val f: [`A] t -> [`B] t
> >   end
> >
> > can be used to constrain the following module
> >
> >   module T : T = struct
> >       type 'a t = unit constraint 'a = [< `A | `B]
> >       let init = ()
> >       let f x = x
> >   end
> >
> > where identity function successfully satisfies the constraint
> >
> >   [`A] t -> [`B] t
> >
> > but in the following module
> >
> >   module T : T = struct
> >       type 'a t = {x:int} constraint 'a = [< `A | `B]
> >       let init = {x=0}
> >       let f x = x
> >   end
> >
> > the same identity function doesn't satisfy.
>
> In the first case, a type abbreviation is used.
> Since ('a t) expands to (unit), the parameter is completely
> ignored, so that you can replace it by anything.
>
> In the second case, you define a concrete type,
> so that the parameter is not forgotten.
> Note that you cannot even use subtyping for that:
>   let f x = (x : [`A] t :> [`B] t)
> fails too.
> But there is an easy workaround, defining in two steps:
>   type u = {x:int}
>   type 'a t = u constraint 'a = [< `A | `B]
>
> Jacques Garrigue
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

  reply	other threads:[~2012-11-27 16:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 11:00 Ivan Gotovchits
2012-11-27 14:08 ` Jacques Garrigue
2012-11-27 15:59   ` Gabriel Scherer [this message]
2012-11-28  3:42     ` Ivan Gotovchits
2012-11-28  8:12       ` Gabriel Scherer
2012-11-28 10:32         ` Ivan Gotovchits
2012-11-28  3:29   ` Ivan Gotovchits

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='CAPFanBFbY8drGNzwy8y6jOaFe=6oSs26PjtcWFMuntcTv8+eCQ@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    --cc=ivg@ieee.org \
    /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