Re: [Caml-list] Record field label locality

[Brighten Godfrey <pbg@cs.berkeley.edu>]

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 = <fun>

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