From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C9EE5BCAF for ; Wed, 29 Jun 2005 11:14:02 +0200 (CEST) Received: from ptb-relay04.plus.net (ptb-relay02.plus.net [212.159.14.213]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j5T9E2BB015116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2005 11:14:02 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay04.plus.net with esmtp (Exim) id 1DnYdo-00016y-Vw for caml-list@yquem.inria.fr; Wed, 29 Jun 2005 10:13:58 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Type abstraction and (polymorphic) equality Date: Wed, 29 Jun 2005 10:12:30 +0100 User-Agent: KMail/1.7.2 References: <20050629.023111.15476874.debian00@tiscali.be> In-Reply-To: <20050629.023111.15476874.debian00@tiscali.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506291012.30612.jon@ffconsultancy.com> X-Miltered: at concorde with ID 42C2665A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 abstraction:01 christophe:01 troestler:01 val:01 bool:01 ocaml:01 iirc:01 sml:01 syntax:01 haskell:01 compilation:01 optimise:01 compilation:01 compiler:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Wednesday 29 June 2005 01:31, Christophe TROESTLER wrote: > One may argue that its my fault: I should have declared from the start > a function > > val eq : t -> t -> bool Yes, if you're doing anything which you think may be extended later then I think it is a good idea to try to discipline yourself in this way (don't use built-in polymorphic equality). > * Is there a solution in the current state of OCaml? (I'll be glad if > there is.) I do not believe so. IIRC, SML has equality types to help with this problem. > * If the first answer is "no", is there a medium term perspective to > bring a solution to this problem? I can see two: > > - one allows to redefine equality for new types, say with a syntax > like > > type t = ... with compare x y = ... > > as this is already done for blocks with custom tags. (BTW, why > aren't Big_int such blocks with an appropriate compare?) That looks lovely. Apparently a similar facility is available in Haskell. However, there are disadvantages. Unless you're doing whole-program compilation, you'll need to carry a compare function with every datum. That's a huge performance cost and it probably isn't too easy to optimise it away. > - One introduces the same capability of providing a special equality > (comparison) for certain types but, during compilation, "expand" > functions till the type for "=" is given by known functions > (something like a "generic" equality). I guess however that that > may cause problems with separate compilation... Yes. It seems that this kind of thing is best done by a MLton-like compiler. If this is a trade-off then I prefer OCaml's current position - MLton is an order of magnitude slower to compile small programs, no dynamic code loading, no marshalling etc. > I'll be glad to hear similar experiences and comments about the above > ideas. I had a similar problem when I extended an AST type to include lazily evaluated information. I suddenly got comparisons raising "function type" exceptions everywhere. The best solution recommended to me was to temporarily replace "=" with my own monomorphic version. That's hardly elegant and only works well if you've only used "=" on the one type that you're interested in. I was convinced that there must be a simpler solution to this problem, using a static checker. However, the more I looked into my seemingly great idea, the harder it got... :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Technical Presentation Software http://www.ffconsultancy.com/products/presenta