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.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C6BAEBB84 for ; Wed, 13 Aug 2008 02:12:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQBAPrDoUhKfSwelGdsb2JhbACRMz4BAQEBCQMKBxEDniiHQAEC X-IronPort-AV: E=Sophos;i="4.32,198,1217800800"; d="scan'208";a="13949348" Received: from yx-out-2324.google.com ([74.125.44.30]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Aug 2008 02:12:23 +0200 Received: by yx-out-2324.google.com with SMTP id 3so992515yxj.3 for ; Tue, 12 Aug 2008 17:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6WZ3I0lzcjHp4OyQ+WCm6Am9eo9MlMOTS2mJTJ268ac=; b=aLipFs/ezVdKTJAKXXJ1ddyFVHc5BHZlwgidP2LUi+mpL+hVuEwkQ8MT4CPgUkO93e HmZNLXAtKYsNL9Bs9vkWQB7RiTZSqlQBcKssdYq6J2dH7Ofo/rlHGDFMUengfuFaNuQx KZ3N3gTbSj9TKbQ5GJMWSIzPwIprvEAvku4h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Xew9lo7ZP2ezsL4DKy3uO4hKByjBtBqGuCLm5EeIb5kJqgcJIYVr2lfBTfFQ+nQM3y f+/8k/gGhnEx00kCrOQHlsG+Oxbu9vKZ9HXEU6FaF6irNQkrR2965hf8S7R/73mq4F45 GxPhDojqqfYXaWvdACMg1Yuywo185F5NpllpI= Received: by 10.150.49.16 with SMTP id w16mr4092859ybw.126.1218586342698; Tue, 12 Aug 2008 17:12:22 -0700 (PDT) Received: from ?192.168.1.116? ( [70.130.128.10]) by mx.google.com with ESMTPS id 34sm5992085yxm.0.2008.08.12.17.12.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Aug 2008 17:12:21 -0700 (PDT) Message-ID: <48A226E3.5050500@gmail.com> Date: Tue, 12 Aug 2008 19:12:19 -0500 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Brighten Godfrey Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Record field label locality References: <200808102038.40534.jon@ffconsultancy.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; locality:01 ocaml:01 arrays:01 compilation:01 translated:01 compilation:01 compiler:01 struct:01 struct:01 edgar:98 wrote:01 typing:01 caml-list:01 int:01 int:01 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. 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? E.