From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6A9F57EE25 for ; Wed, 12 Jun 2013 04:37:06 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcAAJLet1GFBoIFnGdsb2JhbABZwliBFA4BAQEBAQgUCTyCIwEBBAEnHAE1AgMLCw4mEiE2BhOHfAMJBad2hEcChHkNS4gAB4xUgiszB4J/YYkhjDuBZ4weiEI X-IPAS-Result: AqcAAJLet1GFBoIFnGdsb2JhbABZwliBFA4BAQEBAQgUCTyCIwEBBAEnHAE1AgMLCw4mEiE2BhOHfAMJBad2hEcChHkNS4gAB4xUgiszB4J/YYkhjDuBZ4weiEI X-IronPort-AV: E=Sophos;i="4.87,848,1363129200"; d="scan'208";a="21407163" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 12 Jun 2013 04:37:02 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 213EF638C; Wed, 12 Jun 2013 11:36:59 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id E65D23997; Wed, 12 Jun 2013 11:36:58 +0900 (JST) DomainKey-Signature: h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id A4BE2252A; Wed, 12 Jun 2013 11:36:58 +0900 (JST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jacques Garrigue In-Reply-To: Date: Wed, 12 Jun 2013 11:36:58 +0900 Cc: Caml List Content-Transfer-Encoding: quoted-printable Message-Id: <9A50D292-682E-48D6-9791-0CE1E733CDD0@math.nagoya-u.ac.jp> References: <69F3B820-75C0-4EA1-B1AF-B70D276E4AEE@math.nagoya-u.ac.jp> To: Jeff Meister X-Mailer: Apple Mail (2.1508) Subject: Re: [Caml-list] Use-site variance in OCaml On 2013/06/12, at 5:58, Jeff Meister wrote: > This seems like a good compromise! However, it raises another question fo= r me. I tried writing ro/wo as modules rather than classes, but my variance= annotations are not accepted then. Specifically, I cannot write: >=20 > module RO : sig > type +'a t > val get : 'a t -> 'a > end =3D struct > type 'a t =3D 'a ref > let get x =3D !x > end >=20 > Aside from the extensibility of class ro, this module looks like an equiv= alent definition. Yet I cannot declare 'a to be covariant, even though the = type t is abstract, and the only operation on t given in the signature is c= ovariant in 'a. Could the same behavior of class ro be allowed for module R= O? >=20 > If so, then it seems like we could have a module-level definition like: m= odule [type] RO =3D struct include module [type of] RW with type +'a t end >=20 > But even without adding that syntax, could the language allow me to manua= lly decompose the module definition of RW into RO and WO? Unfortunately, the way variance is computed for abstract types is very diff= erent of the one for objects. Currently, for an abstract type to be covariant, its implementation must be= covariant. This problem was discussed in my paper on relaxing the value restriction. It would be interesting to find a good criterion for allowing this kind of= variance improvement, and prove it. Note that it can be tricky, as abstraction interacts in subtle ways with th= e rest of the language. Jacques Garrigue=