caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: oleg@okmij.org
To: caml-list@inria.fr
Cc: Didier.Remy@inria.fr
Subject: Re: [Caml-list] Robust left to right flow for record disambiguation
Date: 26 Oct 2013 06:05:43 -0000	[thread overview]
Message-ID: <20131026060543.55301.qmail@www1.g3.pair.com> (raw)
In-Reply-To: <526A55AE.8080208@inria.fr>


First, I'd like to state the agreement with:
> 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.

It seems the declarative model of type inference -- type checker
non-deterministically choosing type parameters -- is best to program
against. This model also gives the implementor enough freedom. If we
need explicit propagation, we should use bi-directional type-checking,
which was designed for such a case.

My main point is that record-type disambiguation is the golden
opportunity for tool writers, making the great case that programming
must be interactive, in interaction between a programmer and a
compiler. For example, when the following snippet is submitted

>   type t = {a: int};;
>   type s = {a: string};;
>   List.map (fun {a} -> a + 1) [({a=2} : t)];; 

the compiler (or a smart editor, acting on compiler's behalf) may tell
the programmer that the type of {a} in fun {a} is ambiguous, and the
possible candidates are the record types 't' and 's'. Which one the
programmer has in mind? The user will choose, and the editor will
remember user's preference by inserting the type annotation on {a} in
the source code.


Interactive programming has becoming a norm in Agda (I think Epigram
was one of the first successful experiments). When the type system is
expressive enough, interactivity seems to be the only way forward.
The alternative, a sufficiently smart compiler, has not worked out
every time it was tried. One of the main reasons the classical Partial
Evaluation (PE) is not used nowadays, despite great promises, is that
it proved hard to program against the very smart, and capricious PE.
A programmer never knows what the PE may think or do. Smart programmers
eventually figured out how to write code tailored to a particular PE,
and have become disappointed in the process [private communication
from a person who wrote a book on PE].


      parent reply	other threads:[~2013-10-26  6:05 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
2013-10-26  6:05       ` oleg [this message]

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=20131026060543.55301.qmail@www1.g3.pair.com \
    --to=oleg@okmij.org \
    --cc=Didier.Remy@inria.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;
as well as URLs for NNTP newsgroup(s).