From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA14740; Mon, 23 Apr 2001 18:42:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA14734 for ; Mon, 23 Apr 2001 18:42:05 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f3NGg2f10977; Mon, 23 Apr 2001 18:42:03 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id JAA03618; Mon, 23 Apr 2001 09:42:02 -0700 (PDT) Date: Mon, 23 Apr 2001 09:42:02 -0700 (PDT) From: Brian Rogoff To: Xavier Leroy cc: John R Harrison , caml-list@inria.fr Subject: Re: [Caml-list] User-defined equality on types? In-Reply-To: <20010423105408.A2049@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 23 Apr 2001, Xavier Leroy wrote: > > I'd like to suggest allowing the user to define a chosen interpretation > > of the equality symbol, and perhaps the polymorphic orderings too, on > > each new (maybe just abstract) data type. This seems natural in the > > context of abstract data types with non-canonical representation, giving > > a kind of quotient type. Has this ever been considered? > > Yes. This was one of the first motivations for Haskell type classes, > I believe. Would the proposed generic polymorphism extension solve this problem? It seems that it would, and it would be a clean solution. John, in case you haven't seen it it is a typeclass like approach where instead of defining a type class you define generic functions which have a typecase and dispatch to the right function (like CLOS). > > Are there good reasons against it? > > It's not easy to implement. One can do it the Haskell way, by passing > around compiler-generated functions as extra arguments, but the > language extensions needed to declare ad-hoc polymorphic operations > and define implementations for these operations at particular types > are fairly complex. I'd rather not add Haskell's type classes to > OCaml :-) That's too bad. I was hoping that one day the nice features of Haskell would get stol^H^H^H^Hused in some future ML and I've always envied Haskeller's their type classes. -- Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr