From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 118EDBBAF for ; Mon, 23 Jun 2008 10:10:39 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncCAHP3XkiBrw8EiGdsb2JhbACSawEBAQ8gnHU X-IronPort-AV: E=Sophos;i="4.27,689,1204498800"; d="scan'208";a="12431905" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 23 Jun 2008 10:10:38 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m5N8AVh1021174 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 23 Jun 2008 10:10:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncCAHP3XkiBrw8EiGdsb2JhbACSawEBAQ8gnHU X-IronPort-AV: E=Sophos;i="4.27,689,1204498800"; d="scan'208";a="12431904" Received: from ext.lri.fr ([129.175.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP; 23 Jun 2008 10:10:38 +0200 Received: from localhost (localhost [127.0.0.1]) by ext.lri.fr (Postfix) with ESMTP id 6044EA48E5; Mon, 23 Jun 2008 10:11:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lri.fr Received: from ext.lri.fr ([127.0.0.1]) by localhost (ext.lri.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEgNe5siTYJ7; Mon, 23 Jun 2008 10:11:13 +0200 (CEST) Received: from smtp.lri.fr (vhost3-23 [129.175.3.23]) by ext.lri.fr (Postfix) with ESMTP id 463FDA488F; Mon, 23 Jun 2008 10:11:13 +0200 (CEST) Received: from [129.175.4.107] (lri4-107 [129.175.4.107]) by smtp.lri.fr (Postfix) with ESMTP id 4518FE0543; Mon, 23 Jun 2008 10:11:22 +0200 (CEST) Message-ID: <485F5B30.5040102@lri.fr> Date: Mon, 23 Jun 2008 10:13:36 +0200 From: Romain Bardou User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: David Teller Cc: OCaml Subject: Re: [Caml-list] Polymorphic variant as a witness? References: <1214089919.6190.13.camel@Blefuscu> In-Reply-To: <1214089919.6190.13.camel@Blefuscu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 485F5A77.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lri:01 val:01 modular:01 generalizing:01 variants:01 ocaml:01 camlp:01 runtime:01 ocamlc:01 variants:01 polymorphic:01 polymorphic:01 encode:01 encode:01 caml-list:01 Hello, Maybe I don't understand entirely your problem but it seems to me that this does what you want: # let x = ref `A;; val x : _[> `A ] ref = {contents = `A} # match !x with `B -> 1 | _ -> 2;; - : int = 2 # x;; - : _[> `A | `B ] ref = {contents = `A} # match !x with `C -> 1 | _ -> 2;; - : int = 2 # x;; - : _[> `A | `B | `C ] ref = {contents = `A} The type of x is expanded with more and more "effects" in a modular fashion (thanks to the _ pattern). In fact you do NOT want to generalize here, as generalizing would allow you to instantiate the type, whereas what you want is some kind of side-effect in the type, as far as I can understand. Did this help or did I miss something? :) -- Romain Bardou David Teller a écrit : > Dear list, > > 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? > > Thanks, > David >