From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id ACB94BC57 for ; Mon, 1 Mar 2010 12:21:13 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswCACcyi0tV2gB4h2dsb2JhbACDBZgeAQEBCgsIBxUiqWSPNIE0gl1qBIly X-IronPort-AV: E=Sophos;i="4.49,559,1262559600"; d="scan'208";a="53787845" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail1-smtp-roc.national.inria.fr with SMTP; 01 Mar 2010 12:21:13 +0100 Received: from [192.168.0.12] (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal1.citycable.ch (Postfix) with ESMTPA id 7C76812C1B5; Mon, 1 Mar 2010 12:21:11 +0100 (CET) Message-ID: <4B8BA350.8090404@citycable.ch> Date: Mon, 01 Mar 2010 12:21:52 +0100 From: Guillaume Yziquel Reply-To: guillaume.yziquel@citycable.ch User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: =?UTF-8?B?U3TDqXBoYW5lIEdsb25kdQ==?= Cc: OCaml List Subject: Re: [Caml-list] Recursive subtyping issue References: <4B887AED.3090005@citycable.ch> <4B88F32C.3050701@citycable.ch> <87k4tyoq3m.fsf@frosties.localdomain> <4B891A0C.604@citycable.ch> <76EDF2F2-8B02-4C97-B083-EC74630D8ECA@mpi-sws.org> <4B896026.2070805@citycable.ch> <4B89780E.5080305@citycable.ch> <4B898179.1000600@citycable.ch> <4B8B9D15.7070300@glondu.net> In-Reply-To: <4B8B9D15.7070300@glondu.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; guillaume:01 guillaume:01 recursive:01 subtyping:01 untyped:01 untyped:01 val:01 val:01 subtyping:01 runtime:01 covariance:01 phane:98 abstract:01 syntactic:01 caml-list:01 St=C3=A9phane Glondu a =C3=A9crit : > Guillaume Yziquel a =C3=A9crit : >>> # type untyped;; >>> type untyped >>> # type 'a typed =3D private untyped;; >>> type 'a typed =3D private untyped >>> # type -'typing tau =3D private obj >>> and 'a t =3D 'a typed tau >>> and obj =3D private untyped tau;; >>> type 'a tau =3D private obj >>> and 'a t =3D 'a typed tau >>> and obj =3D private untyped tau >>> # let f : 'a t -> obj =3D fun x -> (x : 'a t :> obj);; >>> val f : 'a t -> obj =3D >>> # let g : obj -> 'a t =3D fun x -> (x : obj :> 'a t);; >>> val g : obj -> 'a t =3D >>> #=20 >=20 > Why don't you just declare 'a t to be synonym for obj in the > implementation of your module, declare them as abstract in its > interface, and export the specially typed identities f and g? Because subtyping seems more efficient than applying a noop function.=20 And this code might run really often, so I do not like very much the=20 idea of having noop functions running really often. Moreover, having conversion functions is not really handy, from a=20 syntactic point of view: It's quite convenient to write something like let f : string -> obj :> string -> float t =3D blah blah blah... than doing the explicit, runtime, casting in the definition of f.=20 Haven't tried the line above, so do not quote me on this, but using=20 covariance and contravariance can make your code cleaner, with less=20 parentheses. What happened is that I was (am currently) doing only the 'a t :> obj=20 subtyping in OCaml-R, and I also have a R.cast function to cast from obj=20 to 'a t. I thought this solution was cleaner than having two conversion functions. I then tried to go the whole way, and get rid of conversion functions=20 altogether. --=20 Guillaume Yziquel http://yziquel.homelinux.org/