On Aug 10, 2008, at 12:38 PM, Jon Harrop wrote:

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

I think I see what you're getting at.  Is it possible to define  
compositionality as follows?:  "Removing a type annotation from  
correct OCaml code results in correct OCaml code."

I would claim that the current syntax (`g.Graph.nodes' in the above  
example) is effectively a type annotation that permits the type  
inference that `g' is a `Graph.t'.  The annoying bit is that you are  
required to use every single time you use a record in `g'.  I  
understand this is not the way the compiler views it.  But it's the  
way I think about it when I'm programming and I suspect many others  
are in the same situation.

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?

> 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'm not sure why the error messages must necessarily be confusing. I  
can see shadowing being confusing, but that can happen already.

Thanks very much for your reply!
~Brighten Godfrey