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.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL 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 B4A29BB84 for ; Wed, 13 Aug 2008 14:48:57 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAOB0okhC+VLtmmdsb2JhbACROD4BAQEBAQgFCAcRA50Wh0gBAg X-IronPort-AV: E=Sophos;i="4.32,201,1217800800"; d="scan'208";a="15966265" Received: from wx-out-0506.google.com ([66.249.82.237]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Aug 2008 14:48:56 +0200 Received: by wx-out-0506.google.com with SMTP id i30so3878738wxd.15 for ; Wed, 13 Aug 2008 05:48:56 -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=PrAP3Q44rgcofOtcgPK8DtiAKsBNQqCOZDYmY7uCMZ0=; b=Denr6LL6oNTCFlo4CPE3cK98/UmALcWl1PtCzIvO4Nm4vD1KTylKqS0O1TQ2KiLmGU Pxbzkn/EV0fHYi4qTOlsEdo8qRWGSKGDPS1FcypS052rdLDHUfYAkGcSNt0c7ouA6jdv UYkOqGz2Alr2WQDRDluGNLIcu91lnkEbLFPZ0= 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=QMu3pE+asOX8yrSeq6FZgo60Kv6n3Uhl/GWEcacrbAPF0lZpGwqby/k+jon9kbfmi5 /2Rx/Yc6EOkPMGLb0X4ZI8TUu8Wk5jg1/FIDXTvbxqEhxFTtiU3SL7B6W2PXixzpWeUw COEzxdz1PROdXcGfE0TCm6rmZPdlQPc///DHQ= Received: by 10.90.97.18 with SMTP id u18mr5123767agb.82.1218631735616; Wed, 13 Aug 2008 05:48:55 -0700 (PDT) Received: from ?192.168.1.116? ( [70.130.128.10]) by mx.google.com with ESMTPS id c44sm183042hsc.16.2008.08.13.05.48.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Aug 2008 05:48:54 -0700 (PDT) Message-ID: <48A2D834.5020508@gmail.com> Date: Wed, 13 Aug 2008 07:48:52 -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> <48A226E3.5050500@gmail.com> <735BE8E5-2CCB-41FA-87E7-8E4027966048@cs.berkeley.edu> In-Reply-To: <735BE8E5-2CCB-41FA-87E7-8E4027966048@cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; locality:01 val:01 compilation:01 compilation:01 compiler:01 compiler:01 ocaml:01 ocaml:01 hmmm:01 inference:01 edgar:98 edgar:98 wrote:01 typing:01 typing:01 Brighten Godfrey wrote: > 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?). > Yes - this breaks separate compilation. > (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'. > In this situation, the type information influences what code is generated. The OCaml developers have been as careful as possible to avoid this. The typing stage of compilation acts as a filter to eliminate incorrect programs, and that's it. I've had my share of ideas of how typing information could usefully connect with code generation, but have been shut down because the ocaml developers (probably rightly) don't want to bridge this separation. (Probably because the quality of the compiler would go down the tubes right quick.) Although... hmmm.. I guess type information is used for some optimization (specializing = for ints and such). Also you lose the compositionality as before - you can't break this function into two parts because the second line "needs" the first line to work. > 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