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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 94C4F7F30D for ; Tue, 12 Mar 2013 16:05:50 +0100 (CET) Received-SPF: None (mail3-smtp-sop.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=mail3-smtp-sop.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 (mail3-smtp-sop.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=mail3-smtp-sop.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 (mail3-smtp-sop.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=mail3-smtp-sop.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: Ap8EAP5CP1GFBoIF/2dsb2JhbABDxGOBXXSCKAEBBAFDATUCDgsOChwSVwYTiA4FrU+EQQKBBoRkiQgHjlozB4JfYYh0jWWQdoJ9HA X-IPAS-Result: Ap8EAP5CP1GFBoIF/2dsb2JhbABDxGOBXXSCKAEBBAFDATUCDgsOChwSVwYTiA4FrU+EQQKBBoRkiQgHjlozB4JfYYh0jWWQdoJ9HA X-IronPort-AV: E=Sophos;i="4.84,831,1355094000"; d="scan'208";a="5823050" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 12 Mar 2013 16:05:48 +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 5E8B06345; Wed, 13 Mar 2013 00:05:46 +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 1C5743962; Wed, 13 Mar 2013 00:05:46 +0900 (JST) DomainKey-Signature: h=Received:Content-Type:Mime-Version:Subject: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 035A63960; Wed, 13 Mar 2013 00:05:45 +0900 (JST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jacques Garrigue In-Reply-To: Date: Wed, 13 Mar 2013 00:05:46 +0900 Cc: Mailing OCaML Content-Transfer-Encoding: quoted-printable Message-Id: References: <513DC595.9020006@frisch.fr> To: Yaron Minsky X-Mailer: Apple Mail (2.1499) Subject: Re: [Caml-list] Record field disambiguation in 4.01 On 2013/03/12, at 3:52, Yaron Minsky wrote: > On Mon, Mar 11, 2013 at 7:52 AM, Alain Frisch wrote: >> The warning tells you something useful: with that record type declaratio= n, >> the reference to field "y" becomes ambiguous, which means in particular = that >> (i) your code might become fragile w.r.t. reordering of type declaration= s, >> (ii) the code might become harder to read (the reader might expect that >> field "y" is typically related to a different record type in your code >> base). Of course, a more explicit warning message, as you suggest, woul= d be >> even better. I have improved the warning (revision 13395), so that it tells you the type= s involved. This should actually help in some hairy situations. >> During the discussion on type-based disambiguation, Mark Shinwell commen= ted >> that most record types in JS code base are defined in nested modules (and >> often exposed only through builder functions) to avoid label clashes. Is >> your example an instance where this is not the case? >=20 > It is. If I'd turned the warning off, would it have in fact picked > the more recent definition? Yes, the new strategy is fully backward-compatible. It just accepts more programs, and there are many new warnings so that you can tune it to your taste. Using all of them is probably self-defe= ating, as for instance warning 42 warns you when something has been accepted that was not accepted before. Jacques=