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 PAA15300; Mon, 15 Apr 2002 15:13:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA14962 for caml-list@pauillac.inria.fr; Mon, 15 Apr 2002 15:13:28 +0200 (MET DST) 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 FAA25144 for ; Sun, 14 Apr 2002 05:10:28 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from sj1-3-4-9.securesites.net (sj1-3-4-9.securesites.net [192.220.127.202]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3E3ARL23370 for ; Sun, 14 Apr 2002 05:10:28 +0200 (MET DST) Received: (qmail 54764 invoked by uid 16863); 14 Apr 2002 03:10:26 -0000 Received: from unknown (HELO localhost) ([192.220.65.223]) (envelope-sender ) by 192.220.65.223 (qmail-ldap-1.03) with SMTP for ; 14 Apr 2002 03:10:26 -0000 Date: Sun, 14 Apr 2002 03:10:26 +0000 (GMT) From: Brian Rogoff To: caml-list@inria.fr Subject: Re: [Caml-list] operator overloading In-Reply-To: <15544.20312.792683.76557@beertje.william.bogus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 13 Apr 2002, William Chesters wrote: > C++'s abstraction mechanism is wonderful on paper: it does the same as > ML functors but is actually efficient (if you use the right compiler). > In practice, though, it's awfully hard to do anything ambitious with > it, because you can't specify signatures and because there are too > many opportunities for ambiguity, so that you end up with an unwieldy > mess which it's impossible for the reader to "find an end of" and > begin unravelling. If ocaml could inline functors it would be a much > better vehicle for building abstract numerical libraries than C++. I agree with the comment about C++, but this is completely unrelated to the issue of overloading. Ada generics behave like functors in this case (Ada 95 generic formal package parameters and null bodied generic packages get you a lot closer than Ada 83 ever did) and the typical implementation strategy is like that of C++. You never get that avalanche of link time errors with Ada 95, and it does have overloading (even overloading based on function return types!). I also agree that some some sort of defunctorizer or even whole program compiler would be a big win in that we could adopt a more heavily functorized style without worrying about performance. > The fact that it _doesn't_ have overloading and _does_ force you to > specify everything transparently is a strength, not a weakness, to my > mind. This seems like trying to make a virtue out of an annoying situation. In languages without type inference, you have to specify more too (separate rant: some explicit typing is good!). I doubt we'll agree on this issue, but let me point out that the proposed overloading mechanism for Caml appears to be "orthogonal", like the object system, so if it is ever added you wouldn't be forced into using it. -- Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners