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_SOFTFAIL 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 B33A4BB84 for ; Thu, 14 Aug 2008 11:03:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQDABqSo0ip5TxXiGdsb2JhbACRegEBAQ8gnQmGMz+BVQ X-IronPort-AV: E=Sophos;i="4.32,208,1217800800"; d="scan'208";a="13985930" Received: from gateway0.eecs.berkeley.edu ([169.229.60.87]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2008 11:03:23 +0200 Received: from [10.0.1.5] (136-152-208-13.VPN.Berkeley.EDU [136.152.208.13]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m7E93DX0013321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Aug 2008 02:03:14 -0700 (PDT) In-Reply-To: <48A2D834.5020508@gmail.com> References: <200808102038.40534.jon@ffconsultancy.com> <48A226E3.5050500@gmail.com> <735BE8E5-2CCB-41FA-87E7-8E4027966048@cs.berkeley.edu> <48A2D834.5020508@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <746B9595-EA63-4E8F-8994-DF815F71D078@cs.berkeley.edu> Cc: Jon Harrop , OCaml List Content-Transfer-Encoding: 7bit From: Brighten Godfrey Subject: Re: [Caml-list] Record field label locality Date: Wed, 13 Aug 2008 23:38:14 -0700 To: Edgar Friendly X-Mailer: Apple Mail (2.753.1) X-Spam: no; 0.00; locality:01 val:01 compilation:01 compilation:01 compiler:01 compiler:01 ocaml:01 ocaml:01 hmmm:01 notation:01 edgar:98 edgar:98 wrote:01 wrote:01 typing:01 On Aug 13, 2008, at 5:48 AM, Edgar Friendly wrote: > 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. > Makes sense. >> (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). This is a good point. Thanks for the explanation. I'm having a hard time thinking of any case other than =,<,> etc where type information would be necessary to determine code generation. On the other hand if you break the separation for those operators, maybe it's OK to break it for record names as well. > 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. It can still work, for example this would work: let garlic_part_1 () = {M2.f2=5; M2.f1="garlic"} let garlic_part_2 x = x.f1 let return_garlic () = garlic_part_2 (garlic_part_1 ()) Using this notation the programmer could of course choose to always specify the full record name (x.M2.f1) if desired. ~Brighten