From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 410827F30A for ; Sun, 10 Mar 2013 02:23:57 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYCAGTfO1GFBoIFjGdsb2JhbABCxEyBdA4BAQEnPIIsAQEEAUMBNQIDCws0EiE2GYgBAwkFqTyEQQKEOQ1MiQgHjEaCFTMHFoJJYYhzjAWBYIEeij6IMg X-IPAS-Result: AiYCAGTfO1GFBoIFjGdsb2JhbABCxEyBdA4BAQEnPIIsAQEEAUMBNQIDCws0EiE2GYgBAwkFqTyEQQKEOQ1MiQgHjEaCFTMHFoJJYYhzjAWBYIEeij6IMg X-IronPort-AV: E=Sophos;i="4.84,816,1355094000"; d="scan'208";a="6264362" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 10 Mar 2013 02:23:55 +0100 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id ACB406137; Sun, 10 Mar 2013 10:23:51 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 2FEFD3962; Sun, 10 Mar 2013 10:23:51 +0900 (JST) DomainKey-Signature: h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id E3A17255D; Sun, 10 Mar 2013 10:23:50 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Jacques Garrigue In-Reply-To: Date: Sun, 10 Mar 2013 10:24:16 +0900 Cc: Mailing OCaML Content-Transfer-Encoding: 7bit Message-Id: <87036D5B-C968-4425-9C6C-04FF45466739@math.nagoya-u.ac.jp> References: To: yminsky@gmail.com X-Mailer: Apple Mail (2.1499) Subject: Re: [Caml-list] Record field disambiguation in 4.01 On 2013/03/10, at 8:39, Yaron Minsky wrote: > This is all in the vein of complaining about a feature that has not > yet been released, so, apologies if all of this is already known and > plans are there for fixing it. > > I've been playing around with a recent 4.01 snapshot of the compiler > in OPAM, and have run against an interesting issue with the record > field disambiguation. In particular, I have some code that looks > roughly like this: > > open Core.Std > > type posn = { x: float; y: float } > > let cross_product p1 p2 = > p1.x *. p2.y -. p1.y *. p2.x > ;; > > And when I try to compile this, I get the following error: > > File "geometry.ml", line 68, characters 13-14: > Warning 41: this use of y is ambiguous. > File "geometry.ml", line 1: > Error: Error-enabled warnings (1 occurrences) > Command exited with code 2. > > This can be fixed by adding an annotation: > > let cross_product p1 (p2:posn) = > p1.x *. p2.y -. p1.y *. p2.x > ;; > > A few concerns: one, it's really hard to figure out where the source > of the conflict is from this message. It would be nice to get some > clue from the compiler as to the two definitions that are conflicting. I see. This shouldn't be difficult. > Also, I'm wondering if anyone has thoughts as to how much code this > change will break? The answer might be "quite a lot", and it might > nonetheless be worth it. But I'm curious what people's thoughts are. Just to clarify: warning 41 is off by default. You should just decide whether you want to enable it for core or not. (The practice of using -w A -warn-error A is dangerous, as new warnings may be added at any time) Jacques