Re: [Caml-list] Record field label locality

[Jon Harrop <jon@ffconsultancy.com>]

On Sunday 10 August 2008 11:04:37 Brighten Godfrey wrote:
> Hi,
>
> Here's something that I've wondered about for years; maybe someone
> here can enlighten me.  One of the few major annoyances in OCaml code
> style is that if I define a record in one module, say a Graph module:
>
>      type t = {
>          nodes : node_t array;
>          }
>
> then when I use it in another module, say with a graph variable `g',
> then I have to write `g.Graph.nodes' rather than `g.nodes'.
>
> I can understand why a record field label has to be uniquely
> identified.  But can't the explicit naming of the Graph module
> usually be avoided, since the compiler will know that `g' is a
> `Graph.t'?  For example if I write something like
>
>      let g : Graph.t = make_graph () in
>      g.nodes
>
> it seems to me that on the second line, the type of `g' and hence the
> meaning of `g.nodes' is unambiguous.

Although this is a topic of debate and is even something that F# has done 
differently in exactly the way you describe for the reason you describe, I 
would certainly not call it a "major annoyance" in OCaml and, in fact, I 
would not even describe the alternative as "better".

In correct OCaml code, function bodies basically don't care what type 
annotations appear above them, including in the function definition. This is 
very useful because it makes the code compositional. The biggest problem with 
the "solution" you refer to is that code is no longer compositional because 
the body of a function now relies upon the type annotations in the function 
definition that it came from in order to be correct: move the body expression 
to another location that does not happen to be preceeded by the same 
annotations and it will no longer compile. Moreover, you have created a 
stumbling block for users who are new to type inference (currently almost all 
newbies) because the error messages they get are unexpected and totally 
unnecessary. Finally, if you had just defined a local record type with a 
field of the same name then your type annotation must shadow it with the 
field from the Graph module, leading to even more obscure errors.

I think breaking the ability to compose expressions is introducing a more 
serious flaw because compositionality is one of the critical ingredients that 
makes OCaml so productive. So my personal opinion is that this approach to 
disambiguation should only be used to avoid an explosion in the number of 
arithmetic operators because that is the only situation where I perceive 
OCaml's current solution to be a major annoyance.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e