RE: [Caml-list] Record field label locality

["David Allsopp" <dra-news@metastack.com>]

> 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.

Until OCaml knows the type of the record, field access can't happen either -
because OCaml doesn't know how to map the field name to a field number
within the block representing the value (I'd highly recommend reading
Section 18.2 of the manual - even if you never plan on linking C code, it
gives a good insight into how the OCaml code you write deals with values).

Edgar's point is that after type-checking you throw away all of the type
inferences. So when generating the code, the code generator sees [x.f1]
again and has no idea what type the field [f1] comes from - with x.M2.f1 it
knows to look at the *declared* type [M2.t] and so discovers that the field
named [f1] will be stored in field 1 of the block representing the value.

> > 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 ())

A brief aside (but I think relevant given your complaint!) - you only have
to name one of the fields fully when declaring a record - so your first line
can be:

let garlic_part_1 () = {M2.f2=5; f1="garlic"}

which does save a little typing!


David