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=1.1 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 81336BC69 for ; Mon, 25 Jun 2007 13:16:09 +0200 (CEST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5PBG9ni020603 for ; Mon, 25 Jun 2007 13:16:09 +0200 Received: by ug-out-1314.google.com with SMTP id p27so1162993ugc for ; Mon, 25 Jun 2007 04:16:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=eC4Hu/VtYelLZTAsns5gPBQEI438mLHOxGaqWgl2ShMT8sD8mDC7f96ytaR9Nti6yjnqps9zgQLSYuWy71jguNN7qPojTxvlCjyPe/bbI2Hv+7B7Ji5v4QKaAiXFYwNbLpts/LHy9kMEvdeLb00+9qQ6P09pSL1Qowp/xgP+tgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Yyxy7L2/SL+dXxtJq5PZBMFY5VEKbDPUT3lQ8owoRfK05He0y4O9DwPthRQlvZmG2aavgakXg4LR5TiOVS99CJ5Q6ZqMGS70/lRQXpdVinrQJz7NB7BZWN2LGlZMQSFyOtNC6EHUlMHURQw2Xq2e68eD40K82PluGiw5sxME+3s= Received: by 10.82.100.1 with SMTP id x1mr12383896bub.1182770168561; Mon, 25 Jun 2007 04:16:08 -0700 (PDT) Received: from ?83.248.129.218? ( [83.248.129.218]) by mx.google.com with ESMTP id i5sm4268418mue.2007.06.25.04.16.07 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jun 2007 04:16:07 -0700 (PDT) Message-ID: <467FA3F8.2030601@lix.polytechnique.fr> Date: Mon, 25 Jun 2007 13:16:08 +0200 From: Arnaud Spiwack User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Execution time of class versus record References: <467E8A6E.9050700@menta.net> <1182709750.20268.22.camel@localhost.localdomain> <467EBD16.7060303@lix.polytechnique.fr> <200706250425.28516.jon@ffconsultancy.com> In-Reply-To: <200706250425.28516.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: Arnaud Spiwack X-Miltered: at discorde with ID 467FA3F9.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lix:01 statically:01 run-time:01 arrays:01 runtime:01 arrays:01 runtime:01 run-time:01 zoology:01 subset:01 compilation:01 ocaml's:01 orthogonal:01 compilation:01 ocaml:01 >> ...btw object coercion should never cost anything >> since they are merely type level tools... >> > > Even in statically typed systems you might well want to shift work to run-time > (e.g. specialization of all-float records/arrays) so I see no reason to > expect coercion to be free. > Well even in dynamically typed languages, a coercion should at runtime cost no more than a soundness check which is part of virtually any operation. But well, I guess you mean that coercion could lead to a kind of object which is optimized in a certain way. Which I hadn't actually thought of, but this should be taken care of at compile time (if I remember well, the arrays of floats are actually compiled a different way, using different get/set primitive, there is still nothing at runtime). So in vew of this, the part of the coercion that'd be shift at run-time would be something rather rare (in the zoology of objects, object that deserve a specific run-time representation sound like a rather spare subset to me), an coincidental. Most coercion would still be no-ops. Am I wrong ? > >> At runtime, I can't see anything to preven objects to be exactly records >> (with a bit of care taken during compilation for method names). >> > > How can the current representation of records handle virtual method dispatch? > I'm not sure I will answer this question properly. But if we're talking of the same thing, virtual methods are not a runtime concern. You can't create object of a virtual class anyway. It's a mere typing issue (and this time for very real, this does not fiddle with any concrete representation of any sort). I guess I haven't understand the question. > >> John >> Skaller's answer is not really convincing either, since the type of a >> value does not change the size of the value, having the same name >> associated to different types does not seem to me a good motivation. >> > > I think this choice makes OCaml's object system more orthogonal to the rest of > the language. > Which specific choice are you refering to right now? (you lost me somewhere on the track). > >> Another lead is maybe something due to module compilation, the >> earlier idea might imply that each module has it's own namespace (it's >> the case for almost everything in OCaml, except, if I'm not mistaking, >> method names >> > > and polymorphic variants. > Indeed. For similar reason I reckon. I wonder how polymorphic variants are handled at compile time. They probably get there label during linking I guess. I can't see how they'd work otherwise. (the OCaml manual states they are a pinch slower than non-polymorphic variants, could someone tell me what is the difference which makes that be?) > >> If it is the motivation for having a runtime >> representation of objects different to that of records, the question >> that raises nex is: what is the motivation for not having >> module-specific namespaces for method names? >> > > If I have two modules containing two classes and I want them to be related, > how can you implement that with structurally-subtyped OO if method names are > local to modules? > Well, you could still use #OtherModule.m to call the other module's "m" method. And using "open OtherModule" as well. I must confess I'm not so sure it really makes a lot of sense to have these like that, but at least it'd be rather consistent. Anyway, since we raised the polymorphic variant point, it sounds unlikely that it'd be impossible to give non-colliding adresses to method names during linking, so this point is rather moot. Arnaud Spiwack