caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: David.Teller@univ-orleans.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Polymorphic variant as a witness?
Date: Mon, 23 Jun 2008 19:27:03 +0900 (JST)	[thread overview]
Message-ID: <20080623.192703.27793304.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <1214089919.6190.13.camel@Blefuscu>

From: David Teller <David.Teller@univ-orleans.fr>

>  I have been thinking for some time about using polymorphic variants to
> encode some aspects of a types-and-effects type system in OCaml using
> Camlp4. While the idea is still quite fuzzy, I have the feeling that, if
> I could have a value (let's call it "witness") with type 
>   [> ] ref
> which I could "touch" into becoming 
>   [> `A] ref
> then
>  [> `A | `B] ref
> etc. as effects `A, `B, etc. appear in the program, it could provide
> interesting information on the effects of the program. 
> 
>  Now, of course, I can't define a value with type ref [> ] or even with
> type ref [> `dummy]. That is, when compiling a module consisting only in
> a declaration such as
>    let witness = ref `dummy
> I'm faced with the good old "cannot be generalised" error message. This
> strikes me as normal -- I'm sure that, with the right modifications on
> witness, I could cause runtime type inconsistencies for any client
> attempting to read the value of witness. However, in this case, I'm not
> going to read any value from witness, ever. I only want to "touch" it
> into becoming something a tad more complex, which I could then look at
> with ocamlc -i or such.
> 
> My question is: is there a way to hijack polymorphic variants into doing
> what I wish? Or to encode this behaviour somehow?

I'm not sure how far you can go with this approach, but if all you
want is to know the type inferred for witness, while this type is
clearly not generalizable (otherwise you won't be able to collect
information), I can think of several tricks.

* first remark: ocamlc -i works even with non-generalizable types, as
  it does not generate any .cmi.

* if you want to be still able to compile, you can write a .mli file
  not including the witness. ocamlc -i on the .ml will still show you
  the witness.

* other solution: put everything inside a function, so that the
  type variable is still generalizable after typing the function.

Hope this helps,

Jacques Garrigue


  parent reply	other threads:[~2008-06-23 10:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-21 23:11 David Teller
2008-06-21 23:27 ` [Caml-list] " Christophe TROESTLER
2008-06-21 23:52   ` David Teller
2008-06-23  8:13 ` Romain Bardou
2008-06-23 10:27 ` Jacques Garrigue [this message]
2008-06-27  6:00   ` David Teller
2008-06-27  6:38     ` Jacques Garrigue
2008-07-04 13:05 ` Polymorphic variant + phantom type as a witness Gleb Alexeyev

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=20080623.192703.27793304.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=David.Teller@univ-orleans.fr \
    --cc=caml-list@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).