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 4D7627EE25 for ; Fri, 25 Oct 2013 14:39:48 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoBAEdlalLB/BfTnGdsb2JhbABZv2KCcgiBOA4BAQEBAQgUCTyCJQEBBAE4QAYLCxgJFg8JAwIBAgFFBwwIAQEXh2YKuXCOCYFRhCwDlCqDYIY7jnQ X-IPAS-Result: AsoBAEdlalLB/BfTnGdsb2JhbABZv2KCcgiBOA4BAQEBAQgUCTyCJQEBBAE4QAYLCxgJFg8JAwIBAgFFBwwIAQEXh2YKuXCOCYFRhCwDlCqDYIY7jnQ X-IronPort-AV: E=Sophos;i="4.93,570,1378850400"; d="scan'208";a="38775050" Received: from msa02.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.211]) by mail2-smtp-roc.national.inria.fr with ESMTP; 25 Oct 2013 14:39:50 +0200 Received: from [192.168.1.112] ([92.151.73.26]) by mwinf5d26 with ME id hQfm1m00c0a1oUC03QfnX3; Fri, 25 Oct 2013 14:39:47 +0200 Message-ID: <526A6693.9010302@frisch.fr> Date: Fri, 25 Oct 2013 14:39:47 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Didier.Remy@inria.fr, caml-list@inria.fr References: <526A37ED.6080901@frisch.fr> <526A55AE.8080208@inria.fr> In-Reply-To: <526A55AE.8080208@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Robust left to right flow for record disambiguation On 10/25/2013 01:27 PM, Didier Remy wrote: > I don't think specifying the information flow between left and right > (always-left-to-right, always-right-to-left, or depending-on-examples) is a > good design. This leads to non predictable type inference and less robust > programs : refactoring a function by just changing the order of parameters > (and consistently changing the order of arguments in all uses of the > function) may break existing programs and also require new annotations. This is already the case, except for people using -principal. I know it is recommended to use this option (at least once in a while), but I doubt many users actually do it. (And FWIW, -principal is so slow on our code base that we cannot actually use it in practice -- this is probably related to the way we use object types.) As a user, I think I'm willing to pay the price of risking having to add a few annotations on the next refactoring if this makes a very common idiom more practical. > Also, such a biased will encourage people to write parameters of functions > in an order that works well for the uses they have in mind. I think it odd > that type inference would have such an influence in choosing the order of > function parameters. If the ordering used for the (specified) information flow were drawn from the actual call site, labeled arguments would be a good solution. Alain