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 561F37F30A for ; Mon, 11 Mar 2013 11:31:41 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.17.12; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.17.12; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.17.12; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUNACqyPVHU4xEMgGdsb2JhbABDvzeFFwIBgVcWDgEBFCgogigBAQUnE08LGAklDwUNGzSIAAEDEwiwbx8rDYlbjEaBflEWgklhA5R1gV+BH4RJhXWIJA X-IPAS-Result: AsUNACqyPVHU4xEMgGdsb2JhbABDvzeFFwIBgVcWDgEBFCgogigBAQUnE08LGAklDwUNGzSIAAEDEwiwbx8rDYlbjEaBflEWgklhA5R1gV+BH4RJhXWIJA X-IronPort-AV: E=Sophos;i="4.84,822,1355094000"; d="scan'208";a="6411516" Received: from mout.web.de ([212.227.17.12]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Mar 2013 11:31:41 +0100 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0Lj2TO-1UlJtS04Z4-00dZno for ; Mon, 11 Mar 2013 11:31:40 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1UF015-000151-KA for caml-list@inria.fr; Mon, 11 Mar 2013 11:31:39 +0100 Date: Mon, 11 Mar 2013 11:31:39 +0100 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20130311103139.GA3683@frosties> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:GIHb2sEkJ3m+MDikZ6LbR1T7spM7kjVblghQAJtJhs/ 37qw/ThJwmXQ28S6GLzFZIJ1kgNlAhFNKOm92JIbd0MUkiom26 0q8pKqzNBKzDs/DMxukIuEwzoTnfu+xS0kkb/jjIpNvfNf17b3 KKMgyquKIr7kFPct8u3lsdFHTwj845cvkPIKg+7jd6laULpF/K qRBdylLuTLJn5Zm3mQfKA== Subject: Re: [Caml-list] Record field disambiguation in 4.01 On Sun, Mar 10, 2013 at 10:33:14AM +0100, Gabriel Scherer wrote: > In case some people feel the need for more context here, the feature that > is discussed was explained in a blog post of Alain Frisch: > http://www.lexifi.com/blog/type-based-selection-label-and-constructors > > On Sun, Mar 10, 2013 at 4:04 AM, Markus Mottl wrote: > > > On Sat, Mar 9, 2013 at 6:39 PM, Yaron Minsky wrote: > > > 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 haven't investigated this, but my bet would be that the ambiguity is > > due to the record in the Core.Std.Date module (y = year). One more reason to be careful with using open. On Sat, Mar 09, 2013 at 06:39:56PM -0500, Yaron Minsky wrote: > 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 > ;; I think this show a problem of how types propagate only in one direction. p1 and p2 are both the same type but p1 gets infered corectly while p2 needs the type annotation to avoid a warning. Lets look at the types: let cross_product p1 p2 = 'a 'b 'c | nothing known yet p1.x *. p2.y -. p1.y *. p2.x ^ label "x" --> posn ^ label "y" --> posn or Date ^ float -> float -> float The "y" is ambiguous but just looking at the .* makes the type Date impossible since Date.y is an integer (I assume). But the information doesn't flow that way. Looking further: ^ label "y" --> posn or Date, but we already know p1 is posn ^ label "x" --> posn, too late for the warning ^ float -> float -> float The use of p2.x fixes the type of p2 to posn. But the information comes too late for the warning when using p2.y. Again, it doesn t flow that way. It would be nice if the type inference and disambiguation would allow type information to flow both ways. Not just from first use to last but also from last use to first. Up, down, left and right in the tree representation of the code. Maybe the use of p2.y with .* (or in general disambiguation on the expected type of the label) because it could lead to hard to follow resolution of ambiguous record use. But the p2.x is a clear indication of what type the programmer wanted. MfG Goswin