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.5 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 32E39BB84 for ; Wed, 13 Aug 2008 03:17:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4DAPjSoUip5TxXiGdsb2JhbACRcgEBAQ8gniWGb0CBUg X-IronPort-AV: E=Sophos;i="4.32,198,1217800800"; d="scan'208";a="15952295" Received: from gateway0.eecs.berkeley.edu ([169.229.60.87]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Aug 2008 03:17:30 +0200 Received: from [128.32.38.78] (dhcp-38-78.EECS.Berkeley.EDU [128.32.38.78]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m7D1HIrF025902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Aug 2008 18:17:19 -0700 (PDT) In-Reply-To: <48A226E3.5050500@gmail.com> References: <200808102038.40534.jon@ffconsultancy.com> <48A226E3.5050500@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <735BE8E5-2CCB-41FA-87E7-8E4027966048@cs.berkeley.edu> Cc: Jon Harrop , caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Brighten Godfrey Subject: Re: [Caml-list] Record field label locality Date: Tue, 12 Aug 2008 18:17:22 -0700 To: Edgar Friendly X-Mailer: Apple Mail (2.753.1) X-Spam: no; 0.00; locality:01 ocaml:01 arrays:01 compilation:01 translated:01 compilation:01 compiler:01 struct:01 struct:01 val:01 compiler:01 ocaml:01 inference:01 edgar:98 edgar:98 On Aug 12, 2008, at 5:12 PM, Edgar Friendly wrote: > Brighten Godfrey wrote: >> Actually, what I want seems to be the way OCaml treats methods in >> objects: given an object, you can name the method directly without >> mentioning its module. I can write a function >> >> let f x = x#some_method "argument" >> >> where `x' might be an object defined in another module, or >> locally. Why >> can't records be handled like this? >> > > 1) Implementation > Record field access is almost identical to array lookup -- internally, > records are stored as arrays and during compilation the field name > gets > translated to the correct index to get. But since type information > goes > away after compilation (including record field names), there's no > way to > do the same kind of dispatch you get with objects. > > Then you run into the problem that the record field labels aren't > global, so you could have the same label as different indexes in > different modules. Thus the compiler needs to know which module that > record field came from to do the conversion to field index. Thanks, that helps. But what about handling typing as with objects, but without the dynamic dispatch that you get with objects? (see below) > 2) Typing of x.field > > Given the following: > > module M1 = struct type t = { f1 : int } end > module M2 = struct type t2 = { f2 : int; f1: string } end > > let get_f1 x = x.f1 > > How should f1 be typed? M1.t -> int or M2.t2 -> string? And how to > deal with separate compilation, such that M1 and M2 aren't even in the > same file as get_f1? Two things come to mind: (1) The type of get_f1 is handled analogously to the way it is handled for objects, something like this: val get_f1 : < x : 'a; .. > -> 'a = I'm guessing that if you did this, you would have to "instantiate" `get_f1' each time it is applied to a new record type, which I assume is inconvenient (or not?). (2) Require that all record field accesses refer to a globally-unique record type, making conversion to a record field index is easy. So the example code Edgar gave would result in a compilation error because the compiler cannot determine which `.f1' field the access refers to. But consider this code: let return_garlic () = let x = {M2.f2=5; M2.f1="garlic"} in x.f1 In line 2, globally unique record field names are given, which allows the compiler to tag variable `x' with type `M2.t2'. Then in line 3, the record field access `x.f1' can only mean `x.M2.f1'. Summary: I can see why it is useful to require that each field access be mapped to a globally-unique record type. OCaml today does this by having the programmer explicitly name a globally-unique record type with every field access. But couldn't this instead be done by type inference? Thanks very much for your reply. ~Brighten