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=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 22B50BC69 for ; Mon, 25 Jun 2007 14:13:09 +0200 (CEST) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5PCD7SI028091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2007 14:13:08 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay02.plus.net with esmtp (Exim) id 1I2nRK-0002uD-Os for caml-list@yquem.inria.fr; Mon, 25 Jun 2007 13:13:07 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Execution time of class versus record Date: Mon, 25 Jun 2007 13:07:16 +0100 User-Agent: KMail/1.9.7 References: <467E8A6E.9050700@menta.net> <200706250425.28516.jon@ffconsultancy.com> <467FA3F8.2030601@lix.polytechnique.fr> In-Reply-To: <467FA3F8.2030601@lix.polytechnique.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706251307.16487.jon@ffconsultancy.com> X-Miltered: at concorde with ID 467FB153.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; arrays:01 runtime:01 run-time:01 run-time:01 zoology:01 subset:01 compiler:01 runtime:01 ocaml's:01 orthogonal:01 structurally:01 variants:01 variants:01 hash:01 enumeration:01 On Monday 25 June 2007 12:16:08 Arnaud Spiwack wrote: > if I remember well, > the arrays of floats are actually compiled a different way, using > different get/set primitive, Yes. > there is still nothing at runtime Not quite: there is now run-time dispatch to the appropriate get/set primitive in polymorphic functions. > ). 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. If these cases were rare, compiler writers would not bother optimizing them. > > 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. Run-time dispatch of virtual functions is the object oriented representation of sum types, so it can require run-time dispatch. > > 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). Structurally sub-typed OOP complements the Hindley-Milner type system, IMHO. > > and polymorphic variants. > > Indeed. For similar reason I reckon. > I wonder how polymorphic variants are handled at compile time. Like an ordinary variant with a single boxed argument but their ID is a hash of the string name of the constructor instead of an enumeration. > 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?) Polymorphic variant type constructors may have different numbers of arguments, so their representation is always boxed whereas multiple-argument variant types are unboxed. For the same reason, there is a difference between: type t = A of int * int and: type t = A of (int * int) The former is unboxed and the latter is boxed (a reference to a pair). The boxing can degrade performance (it can also improve performance!). Pattern matching is also less efficient for polymorphic variants. Look at the compiled bytecode, for example: type x = A | B | C let f = function | A -> 0 | B -> 1 | C -> 2 compiles to an efficient O(1) virtual table: L1: acc 0 switch 5 4 3/ L5: const 0 return 1 L4: const 1 return 1 L3: const 2 return 1 but: let g = function | `A -> 0 | `B -> 1 | `C -> 2 compiles to O(n) comparisons: L1: acc 0 push const 66 neqint branchifnot L3 acc 0 push const 67 leint branchifnot L4 const 2 return 1 L4: const 0 return 1 L3: const 1 return 1 > > 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. I was referring to virtual function dispatch and not the explicit invocation of a particular member. Consider this example: module A = struct let foo = object method f n = n+1 end end;; module B = struct let bar = object method f n = n+2 end end;; let apply o = o#f;; apply A.foo 0;; apply B.bar 0;; If modules imposed separate namespaces then the objects in the modules A and B could not be related, so you could not use them for dispatch in this way (probably a very common use of objects as well). -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e