Not being here a type system's expert so excuse if I did a serious mistake
or I said something trivial.

Wouldn't make sense to perform the unification of the arguments (GADT
constructors and function arguments), in both ways? First propagate the
type information left right and then right left, and then finally unify the
results? Alternatively, we could also add check such that if the left right
type checking fails (being not principal), then we try also right to left.



On Fri, Oct 25, 2013 at 1:39 PM, Alain Frisch <alain@frisch.fr> wrote:

> 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
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/**arc/caml-list<https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-**bugs<http://caml.inria.fr/bin/caml-bugs>
>