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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 3E787BB84 for ; Sun, 10 Aug 2008 21:37:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcBAGvgnkjUnw4SjWdsb2JhbACCK48sAQEBAQcHBgcTlw4 X-IronPort-AV: E=Sophos;i="4.31,339,1215381600"; d="scan'208";a="15887243" Received: from pih-relay05.plus.net ([212.159.14.18]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 10 Aug 2008 21:37:43 +0200 Received: from [90.198.246.64] (helo=beast.local) by pih-relay05.plus.net with esmtpa (Exim) id 1KSGjW-0006Di-MD for caml-list@yquem.inria.fr; Sun, 10 Aug 2008 20:37:42 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Record field label locality Date: Sun, 10 Aug 2008 20:38:39 +0100 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808102038.40534.jon@ffconsultancy.com> X-Plusnet-Relay: 9cb8bfd6c95e22381e37f951448dbf7f X-Spam: no; 0.00; locality:01 ocaml:01 nodes:01 node:01 avoided:01 compiler:01 nodes:01 unambiguous:01 ocaml:01 annotations:01 annotations:01 inference:01 ocaml's:01 frog:98 wrote:01 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