From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Didier.Remy@inria.fr>
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 1A93A7EE42
	for <caml-list@sympa.inria.fr>; Fri, 25 Oct 2013 13:27:43 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.93,569,1378850400"; 
   d="scan'208";a="38764391"
Received: from arbois.inria.fr (HELO [128.93.11.104]) ([128.93.11.104])
  by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Oct 2013 13:27:45 +0200
Message-ID: <526A55AE.8080208@inria.fr>
Date: Fri, 25 Oct 2013 13:27:42 +0200
From: Didier Remy <Didier.Remy@inria.fr>
Reply-To: Didier.Remy@inria.fr
Organization: INRIA Rocquencourt
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: caml-list@inria.fr
References: <CANcqPu70B1kOEtZgiNH1jxBTAUoo9dyp6Dt9hKb7OXwa7f1Wig@mail.gmail.com> <C34DDC63-35B3-43EA-8361-13160A4A849E@math.nagoya-u.ac.jp> <526A37ED.6080901@frisch.fr>
In-Reply-To: <526A37ED.6080901@frisch.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

> There is already a left-to-right propagation between arguments:
>
>   type t = {a: int};;
>   type s = {a: string};;
>   List.map (fun ({a} : t) -> a + 1) [{a=2}];;   (* accepted *)
>   List.map (fun {a} -> a + 1) [({a=2} : t)];;   (* rejected *)

Yes, but as you notice this is not principal.

> With -principal, the first case is reported as non principal (warning 18).
>
> Is there any practical or theoretical problem with specifying the information
> flow in order to make it principal?

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.

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.

         Didier