From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C3300BB81 for ; Thu, 12 Jan 2006 04:22:37 +0100 (CET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k0C3MZ0S002701 for ; Thu, 12 Jan 2006 04:22:37 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id k0C3MVCF024535; Thu, 12 Jan 2006 12:22:32 +0900 (JST) Date: Thu, 12 Jan 2006 12:22:30 +0900 (JST) Message-Id: <20060112.122230.45186948.garrigue@math.nagoya-u.ac.jp> To: jonathan.roewen@gmail.com Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Mixing variant types... From: Jacques Garrigue In-Reply-To: References: X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43C5CB7B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 coerced:01 toplevel:01 subtype:01 subtype:01 semantics:01 simulate:01 subtyping:01 expression:01 jacques:01 jacques:01 variant:02 variant:02 parameter:02 covariant:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: Jonathan Roewen > File "window_system.ml", line 99, characters 23-50: > This expression cannot be coerced to type > ws_event = (window * [ `New_window | `Repaint ]) Event.event; > it has type (window * event) Event.event but is here used with type > ws_event = (window * [ `New_window | `Repaint ]) Event.event > Type event = [ `Repaint ] is not compatible with type > [ `New_window | `Repaint ] > The first variant type does not allow tag(s) `New_window > > The toplevel has just proven to me that this can be done, so I don't > understand what's going on here. The reason is simple: Event.event is not marked ascovariant in its parameter. So even if t1 is a subtype of t2, this does not imply that t1 Event.event will be a subtype of t2 Event.event. After thinking a bit of the semantics, it seems that it would be safe to make Event.event covariant. Of course Event.channel cannot be made covariant, as it can be used both to send and receive values. You can already simulate subtyping using Event.wrap: Event.wrap e (fun x -> (x : t1 :> t2)) will turn a t1 event into a t2 event. (So this probably means that Event.event should be covariant to start with...) For practical applications, the solution suggested by skaller might be satisfactory too. Jacques