caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: markus.mottl@gmail.com
Cc: yminsky@cs.cornell.edu, caml-list@inria.fr
Subject: Re: [Caml-list] Phantom types and read-only variables
Date: Sun, 06 Feb 2005 09:48:49 +0900 (JST)	[thread overview]
Message-ID: <20050206.094849.93018777.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <20050205192113.GA26897@mobile>

From: Markus Mottl <markus.mottl@gmail.com>

> Hm, it seems to me that the compiler could do a better job here.
> 
> Instead of writing:
> 
>   type 'a t = { mutable value: int }
> 
> write:
> 
>   type v = { mutable value: int }
>   type 'a t = v
> 
> This should make the code compile.

Indeed, by doing that you make t extensible to a type that drops the
type parameter, meaning that type inference will never try to unify
the parameter.

A more direct way would be to define

  type 'a t = int ref

Alternatively, you could just slightly change the definition of
freeze, to allow dropping the parameter

  # type 'a t = { mutable value: int } ;;
  # let freeze ({value=_} as v) = v ;;
  val freeze : 'a t -> 'b t = <fun>

> I think the compiler should be able to infer automatically that 'a isn't
> used on the right hand side of the record definition (i.e. that it is
> just a phantom type) without using the hint of a separate monomorphic
> record definition.  I guess this feature should be trivial to add.
> Maybe in the next release? :-)

Actually, this is a bit problematic.
Types defined as abbreviations are automatically expanded during
unification, so that unused parameters disappear.
But datatypes cannot be expanded, so their parameters are going to be
unified. Avoiding it would mean checking whether the parameters appear
in the real definition during unification. This is possible, but would
change the semantics of unification, something you want to be careful
about.

Actually ocaml 3.09 will go in the somehow opposite direction:
allowing private types to behave as phantom types. Currently private
types have their variance automatically inferred from their
definition, meaning you can use the above subtyping trick even after
the type is made private, but considering the fact they are
semi-abstract, it seems more natural to require their variance to be
explicitly given, allowing one to disallow such subtyping.

Jacques Garrigue


      reply	other threads:[~2005-02-06  0:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-05 16:50 Yaron Minsky
2005-02-05 17:24 ` Yaron Minsky
2005-02-05 20:21   ` Ethan Aubin
2005-02-05 18:34 ` [Caml-list] " Remi Vanicat
2005-02-05 19:21 ` Markus Mottl
2005-02-06  0:48   ` Jacques Garrigue [this message]

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=20050206.094849.93018777.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=markus.mottl@gmail.com \
    --cc=yminsky@cs.cornell.edu \
    /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).