Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Wojciech Meyer <wojciech.meyer@gmail.com>
To: Alain Frisch <alain@frisch.fr>
Cc: Didier Remy <Didier.Remy@inria.fr>, Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Robust left to right flow for record disambiguation
Date: Fri, 25 Oct 2013 14:06:21 +0100	[thread overview]
Message-ID: <CAOg1smANR4+242i1BA-ee7qzNFEGq2Vrfyqf6_9pOLcKEhL7aw@mail.gmail.com> (raw)
In-Reply-To: <526A6693.9010302@frisch.fr>

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

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>
>

[-- Attachment #2: Type: text/html, Size: 3286 bytes --]

  reply	other threads:[~2013-10-25 13:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23 20:52 Bob Zhang
2013-10-24  1:40 ` Jacques Garrigue
2013-10-24  3:11   ` Bob Zhang
2013-10-25  9:20   ` Alain Frisch
2013-10-25 11:27     ` Didier Remy
2013-10-25 12:39       ` Alain Frisch
2013-10-25 13:06         ` Wojciech Meyer [this message]
2013-10-26  6:05       ` oleg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOg1smANR4+242i1BA-ee7qzNFEGq2Vrfyqf6_9pOLcKEhL7aw@mail.gmail.com \
    --to=wojciech.meyer@gmail.com \
    --cc=Didier.Remy@inria.fr \
    --cc=alain@frisch.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox