caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: "Tom Primožič" <tom.primozic@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Type Inference and Overloading
Date: Mon, 10 Apr 2006 21:57:43 +1000	[thread overview]
Message-ID: <1144670263.8633.50.camel@rosella.wigram> (raw)
In-Reply-To: <c1490a380604100151s256d05y13cc8ffa11580770@mail.gmail.com>

On Mon, 2006-04-10 at 10:51 +0200, Tom Primožič wrote:
> I would like to pose one really perverse question (perverse because it
> mentions overloading). 
> 
> I have done a lot of thinking over the subject of type inference with
> overloading. I have also read a lot, however, no paper satisfied me. I
> don't like constraints (neither GCaml nor System CT like) as i find
> them too difficult for the user to understand. 

I couldn't understand the constraints of CT either. 

I think (if I understand correctly) that GCaml is simple.
A generic function is called 'as if it were polymorphic'.
Which implementation is used is calculated independently.
Thus there is no impact on the existing type inference
engine for calls to generics, there are new rules for
choosing the implementation based on the construction
of the generic function.

I suggest you look at the rules the new version of C# uses,
it can do both overloading and argument type inference,
with some constraints (I don't understand them either :)

> I have been trying to think of another mechanism for inferring
> overloaded types, but have yet been unsuccessful. 

Generalised Unification. Keep a set of sets of equations.
Each application leads to a set of alternatives.

For each alternative, duplicate the sets of equations,
then add that alternative to each set. Now unify as much
as possible, go on to the next set.

This is VERY expensive. A cut occurs when a function
'goes out of scope'. At the point, the type of the function
must be established (that is, for each argument's type variable,
the same assignment must exist in all the sets). If not,
the program is ambiguous.

BTW: just a pie in the sky :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2006-04-10 11:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-10  8:51 Tom Primožič
2006-04-10 11:57 ` skaller [this message]
2006-04-10 13:42 ` [Caml-list] " Andrej Bauer
2006-04-10 14:06 ` Brian Hurt
2006-04-10 14:43   ` Tom Primožič
2006-04-11 16:11 ` Stefan Monnier

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=1144670263.8633.50.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=tom.primozic@gmail.com \
    /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).