From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTP id D92165D4 for ; Thu, 6 Sep 2018 23:35:18 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.53,339,1531778400"; d="scan'208";a="345312945" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 07 Sep 2018 01:35:16 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 84842824DC; Fri, 7 Sep 2018 01:35:16 +0200 (CEST) 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 08AA8824B2 for ; Fri, 7 Sep 2018 01:35:07 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=garrigue@math.nagoya-u.ac.jp; spf=None smtp.mailfrom=garrigue@math.nagoya-u.ac.jp; spf=None smtp.helo=postmaster@ms.math.nagoya-u.ac.jp IronPort-PHdr: =?us-ascii?q?9a23=3AS95hQByS0X9uqxfXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?2+MVIJqq85mqBkHD//Il1AaPAd2Eraocw8Pt8InYEVQa5piAtH1QOLdtbDQizf?= =?us-ascii?q?ssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1?= =?us-ascii?q?JuPoEYLOksi7ze+/94HRbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeu?= =?us-ascii?q?BWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbO?= =?us-ascii?q?SxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDtU7s6RSqt4LtqSB/wiS?= =?us-ascii?q?cIKTg58H3MisdtiK5XuQ+tqwBjz4LRZoyeKfhwcb7Hfd4CWWVOUdtfWSxDDY2y?= =?us-ascii?q?YIUBDOQBM/hfoYTmu1sDrx6+CRWsBO/z1DNFgGL9060g0+QmFAHLxAguEMgSv3?= =?us-ascii?q?TNsdX6KrwSWv20wqbS1zXDdfJW2Tjg6IfWbxsspv6MUqhqccrLyEkvGB7FgUuL?= =?us-ascii?q?pIzgJTyVyuQNv3Kd7+V6WuKvjG4mpBtorjiy3MsjkJXGipgXylDc7Ch0xps+K9?= =?us-ascii?q?6gSENjfNKpHpVduzubOodsX88vTX1ktDwnxrEboZK2fCsHxI46yxPfaPGLaZWE?= =?us-ascii?q?7gzgWeqLPDt1hHBodbSijBio60eg0PfzVsys3VZKsCVFlt7Mu2gI1xzI8MSHT+?= =?us-ascii?q?Fy/luh2TqV0QDc8O5EIUc0lKXBMpIh36Q8mYAPvkjZHC/2gF36jK6Qdko65uil?= =?us-ascii?q?8/nrb7voq5OGNoJ4kBzyP6oylsClHOg0LxACX22B9uS90L3j81f5QLJPjvAuna?= =?us-ascii?q?nWqoraJd4apq62Hg9azJ0u6xOlADe60NQUh38HI0hKeBKAj4nmIUjCIO3iAfil?= =?us-ascii?q?n1ugijVrx+jeMr37HprNNmTDkKvmfbtl90FT0g8zzdRG65JQC7EBO+7zV1TqtN?= =?us-ascii?q?3YCx85Kxa7z/zmCNV7zIMeWHiADrWXMKPIqVWI/P4gI/GQZI8JvzbwM+Ql6OT1?= =?us-ascii?q?jX8imF8QZqio3ZoSaH+jBPRpOV+VYXvqgtcbEGcFpBAyTOLwiA7KbTkGSnCoXq?= =?us-ascii?q?k7rg0yE5mnRdPOQJqsi7vHwC6gBZx+Z2ZcC1nKH22+JKueXPJZSiuZO9JsiXQr?= =?us-ascii?q?XKK7SoA82Fn6uwbg0btoM+f8/yQEtdTl3ddy9uSWiFc7/np2F5LOgCm2U2hokz?= =?us-ascii?q?ZQFHcN16dlrBk4kw/biPkqs7ljDdVWoshxfEI/PJ/YwfZ9DoqrCAfIYtfPTl+p?= =?us-ascii?q?RcSvRCx3R9l3wcdcOx8hSeXntQjK2m+RO5FQj6aCXsVm96vA3z73Lsl62n+Dye?= =?us-ascii?q?8ohB8kWpkXbDD0tutE7wHWQrXxvQCZmqKtL/hO2TWL8W6fzSyItU5fQQc1TOPM?= =?us-ascii?q?VjYdfhmOoA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgA+uZFblwuCBoVbGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQ2fCiMY41QmCoBCoRsAoN1BgY0FAECAQECAQEBAQETAQEBAQEIFgZ?= =?us-ascii?q?MDII1JAGCXwEFOgYBATcBDwsYLlcGgzSCAaN6gh2CdQEBBYFwgwEZggIIinWCA?= =?us-ascii?q?IE5H4IeLogwgiaGLQeHCz8vjUYJj38XiFSGE5EZgmOBWIF2TTg7KgGCQT6BWxq?= =?us-ascii?q?GVIdbYI1eAQE?= X-IPAS-Result: =?us-ascii?q?A0AUAgA+uZFblwuCBoVbGgEBAQEBAgEBAQEIAQEBAYQ2fCi?= =?us-ascii?q?MY41QmCoBCoRsAoN1BgY0FAECAQECAQEBAQETAQEBAQEIFgZMDII1JAGCXwEFO?= =?us-ascii?q?gYBATcBDwsYLlcGgzSCAaN6gh2CdQEBBYFwgwEZggIIinWCAIE5H4IeLogwgia?= =?us-ascii?q?GLQeHCz8vjUYJj38XiFSGE5EZgmOBWIF2TTg7KgGCQT6BWxqGVIdbYI1eAQE?= X-IronPort-AV: E=Sophos;i="5.53,339,1531778400"; d="scan'208";a="345312900" Received: from bsd20.math.nagoya-u.ac.jp (HELO ms.math.nagoya-u.ac.jp) ([133.6.130.11]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2018 01:35:04 +0200 Received: from [192.168.0.12] (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 4C217893503; Fri, 7 Sep 2018 08:35:01 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=math.nagoya-u.ac.jp; s=20160220; t=1536276901; bh=c+ztrkkHKFxWPkjI/iMwJePS+0dtivI02DHhv4hJqXo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gaeeO1C/eLnvsjFJ5dhuhRpy41W8hBwOvaruThTDOpq8hIauaqPpF4wZmCR5sZsHw udUgA1ch+BB2Vy4laGGbJI5hCkZtE5Y4bf3YA6lOLM4vD9fHjsqSOZ1YH1IMPejcSm 32C0tf1xdhmmikFTLW0BEUOZyFEtug2HwoO+iLMU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jacques Garrigue In-Reply-To: <20180906141809.6m4vcwnsqqqbsack@gargamel> Date: Fri, 7 Sep 2018 08:34:59 +0900 Cc: Mailing List OCaml Content-Transfer-Encoding: 7bit Message-Id: <6FB58BFB-B903-4B22-8F03-4124FB178F32@math.nagoya-u.ac.jp> References: <20180906113622.lcuamhs6g6juv2r5@gargamel> <20180906130314.ymqnpcxbrz5d7tj4@gargamel> <5972F2FD-82AA-4C68-BE0A-D913A2D08658@math.nagoya-u.ac.jp> <20180906141809.6m4vcwnsqqqbsack@gargamel> To: Enrico Tassi X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (ms.math.nagoya-u.ac.jp [0.0.0.0]); Fri, 07 Sep 2018 08:35:01 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99.2 at bsdserver20 X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bsdserver20.math.nagoya-u.ac.jp Subject: Re: [Caml-list] How to rename a record field Reply-To: Jacques Garrigue X-Loop: caml-list@inria.fr X-Sequence: 17059 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2018/09/06 23:18, Enrico Tassi wrote: > > On Thu, Sep 06, 2018 at 10:17:25PM +0900, Jacques Garrigue wrote: >> Records being the dual of variants, all the arguments apply. >> Namely, if the name is allowed to change, field access can no longer >> be seen as the intuitive projection (by name rather than position, since >> only name information is available in the source code). >> Field name disambiguation works in the same way too. > > Thanks. I see why in the general case this makes the source code > ambiguous. > >>> type old = { bad : int; stuff : bool } >>> type t = old = { good : int; stuff : bool } > > But in a case as simple as this one where names are either different > or occur in the same position I believe there is no ambiguity. > "stuff" would always resolve to position 2 while both > "good" and "bad" to position 1. Suppose that (maybe in another module) you have type u = old = {bad : int; good : bool } Now, a piece of code containing x.good could mean either (x : old).bad or (x : old).stuff, with x having a type compatible with both t and u simultaneously. Here it happens that int and bool being incompatible, a wrong interpretation would probably cause an error somewhere, but this looks rather unpredictable. Worse, in ocaml it is not always decidable whether two types might be equal or not, so a definition time restriction could be hard to predict too. Jacques Garrigue -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs