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 B9F06BC57 for ; Mon, 1 Mar 2010 14:05:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswCAMNKi0tV2gB4h2dsb2JhbACDBZgfAQEBCgsIBxUiqgOPNIE0gl1qBIly X-IronPort-AV: E=Sophos;i="4.49,560,1262559600"; d="scan'208";a="53796521" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail1-smtp-roc.national.inria.fr with SMTP; 01 Mar 2010 14:05:28 +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 A5BEE12C6FB; Mon, 1 Mar 2010 14:05:26 +0100 (CET) Message-ID: <4B8BBBC6.8070302@citycable.ch> Date: Mon, 01 Mar 2010 14:06:14 +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> <4B8BA350.8090404@citycable.ch> <4B8BB2EF.1010008@glondu.net> In-Reply-To: <4B8BB2EF.1010008@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 subtyping:01 fwiw:01 bindings:01 runtime:01 runtime:01 bindings:01 syntax:01 untyped:01 annotations:01 ocaml:01 mli:01 St=C3=A9phane Glondu a =C3=A9crit : > Guillaume Yziquel a =C3=A9crit : >> Because subtyping seems more efficient than applying a noop function. >> And this code might run really often, so I do not like very much the >> idea of having noop functions running really often. >=20 > FWIW, I don't think you have any penalty if you declare your identities > as externals like Obj.{repr,obj,magic}. Yuk, some might say... but we > are in the context of bindings to other languages anyway. Yuk indeed. The subtyping was also a way to avoid Obj.magic in the first=20 place and keep doing things cleanly. I'm not so sure about runtime penalty in this context. >> Moreover, having conversion functions is not really handy, from a >> 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 > It's more convenient for me write letters and parentheses than the > symbol ":>" :-) That's a matter of taste, I guess :-) > IIUC, these conversion function are not to be used often, are they? Wha= t > you want is the equivalent of Obj.{repr,obj}, but for values of some > other language, right? Yes, for the values of some other language. It depends: they are to be used often for people wanting to make=20 bindings of R / Python code. (Even tough I plan to use syntax extensions=20 to ease the pain, something like 'module Nltk =3D python module nltk'. Bu= t=20 that's a long term perspective. For people using the binded code, subtyping shouldn't be necessary. > Are you planning to leak your "tau", "typed" and "untyped" types out of > the module? If so, inferred types are likely to refer to those, which > might be very confusing (unless you resort to a lot of type > annotations). If not, you'll have to use explicitly the coercion > functions outside of the module anyway. Yes. I'm not satisfied with this. (Renaming 'tau' to 'wrapped' would be=20 better, I guess). But somehow, I believe that it's an OCaml issue rather than an issue=20 with my approach. I mean, why should it be impossible to *express* in=20 the .mli file something like type 'a t =3D private obj and obj =3D privat= e=20 'a t without resorting to extra intermediary types and contravariant=20 phantom types? Couldn't we just dump the type inequations and=20 co/contra-variance information (which would require another syntax for=20 types, I guess)? But there's another problem for weirder typings that would need 3=20 different categories of types (R ?). 2 conversion functions is OK. 6=20 conversion functions is clearly a pain... And concerning R's quirky type=20 system, I'm probably optimistic with the number 3. --=20 Guillaume Yziquel http://yziquel.homelinux.org/