From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 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 7F9E2BC69 for ; Sat, 12 May 2007 08:43:33 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4C6hU1D032196 for ; Sat, 12 May 2007 08:43:32 +0200 X-IronPort-AV: E=Sophos;i="4.14,525,1170595800"; d="scan'208";a="126523927" Received: from ppp8-148.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.8.148]) by ipmail01.adl2.internode.on.net with ESMTP; 12 May 2007 16:13:29 +0930 Subject: Re: [Caml-list] Custom operators in the revised syntax From: skaller To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200705120659.49753.jon@ffconsultancy.com> References: <200705120547.06083.jon@ffconsultancy.com> <1178948713.14691.89.camel@rosella.wigram> <200705120659.49753.jon@ffconsultancy.com> Content-Type: text/plain Date: Sat, 12 May 2007 16:43:28 +1000 Message-Id: <1178952208.14691.116.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46456212.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; syntax:01 0100,:01 unification:01 variants:01 constructors:01 rtti:01 runtime:01 typedef:01 compiler:01 emits:01 intersection:01 bindings:01 bindings:01 sourceforge:01 polymorphic:01 On Sat, 2007-05-12 at 06:59 +0100, Jon Harrop wrote: > > If ANYONE knows an algorithm that can do unification with > > sets of types, that is, with a union type, I'd sure like > > to know it! > > Isn't this exactly what polymorphic variants do? I don't think so, but here I need a theorist to give a proper explanation. I suspect part of what pm-variants do does indeed rely on the fact that you have a finite set of discrete constructors (variant tags). However here, you will fail to get a unique constructor a LOT of the time .. and that is OK, you just dispatch at run time on the tag. But int, float, long etc don't have tags or associated RTTI in Felix when used as values (they do if they're boxed .. but they're boxed by using a variant .. and that's a different type). The point is that here, we actually need to resolve to a single type, equivalent to pm-variants resolving to a single constructor. So the situation is different: f: [`Int of int | `Float of float] -> int makes sense, use runtime dispatch but: f: [int | float] -> int is nonsense -- unless the argument is ignored -- because you *cannot* dispatch. In Felix: typedef nums = typesetof(int,float); fun f[t in nums]: t -> int = "(int)$1"; makes sense, but only because it leverages C/C++ generic programming stuff, that is, it is extensionally polymorphic (the compiler emits the code for every call point and relies on (int)x being a generic in C). Particularly, this *actually* means the same as: fun f: int -> int = "(int)$1"; fun f: float -> int = "(int)$1"; that is, it's sugar for a type schema (first order universal quantification) with an intersection constraint. In Felix this kind of 'sugar' is more than just useful for reducing several overloaded bindings to one, it is quite mandatory for making it possible to write bindings to libraries like OpenGL where the types are aliases for unknown integer types. So a function like: void GLsetCoord(x:GLint, y:GLint) is modelled by proc GLsetCoord: !ints * !ints; which means you can call it like: GLsetCoord (1, 2L); instead of having to cast every argument to GLint. -- John Skaller Felix, successor to C++: http://felix.sf.net