From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A76FEBB81 for ; Mon, 10 Apr 2006 13:57:55 +0200 (CEST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k3ABvrJm031639 for ; Mon, 10 Apr 2006 13:57:54 +0200 Received: from rosella (ppp36-94.lns2.syd6.internode.on.net [59.167.36.94]) by ash25e.internode.on.net (8.13.6/8.13.5) with ESMTP id k3ABviOP079253; Mon, 10 Apr 2006 21:27:45 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Type Inference and Overloading From: skaller To: Tom =?iso-8859-2?Q?Primo=BEi=E8?= Cc: caml-list@yquem.inria.fr In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Mon, 10 Apr 2006 21:57:43 +1000 Message-Id: <1144670263.8633.50.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 443A4841.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; inference:01 overloading:01 overloading:01 inference:01 gcaml:01 gcaml:01 'as:01 unification:01 unify:01 2006:98 wrote:01 sourceforge:01 caml-list:01 argument:01 generics:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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 Felix, successor to C++: http://felix.sf.net