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 FAA02886; Tue, 3 Jun 2003 05:42:48 +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 FAA02839 for ; Tue, 3 Jun 2003 05:42:47 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h533giH16316 for ; Tue, 3 Jun 2003 05:42:45 +0200 (MET DST) Received: from ozemail.com.au (203-219-225-76-syd-ts24-2600.tpgi.com.au [203.219.225.76]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h533ggN10448 for ; Tue, 3 Jun 2003 13:42:42 +1000 Message-ID: <3EDC1931.80307@ozemail.com.au> Date: Tue, 03 Jun 2003 13:42:41 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "caml-list@inria.fr" Subject: Re: [Caml-list] Why are arithmetic functions not polymorph? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ozemail:01 caml-list:01 brogoff:01 gcaml:01 implicitly:01 model:01 verbose:01 toxteth:01 glebe:01 2037,:01 9660:01 0850:01 unify:01 speakeasy:01 overloading:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk brogoff@speakeasy.net wrote: > I actually think overloading can be *really* *really* good. The problem, or > rather, one of the many problems, with C++ IMO is that it has overloading and > implicit conversions of types. That's a bad combination. > > One nice thing about GCaml is that it shouldn't bother people like you who > dislike overloading. The overloading is fairly explicit and closed world. In Felix I took the opposite approach. First, overloading requires an exact match, and there are no implicit conversions, so it's fairly easy to decide which overload with a closed type is selected. Second, unlike C++, and totally opposite to GCaml, functions are looked up by (name,signature) which means a function with the wrong signature doesn't hide one further up scope. In C++ the overload set is always in the same scope, since lookup is by name, then tries for a match. (This tends to force all templates and overloadable entities into the top level scope). GCaml requires you to package up all the overloads in one place. So you might say: GCaml - explicitly constructed closed world C++ - implicitly constructed partially closed Felix - implicitly constructed fully open Third, Felix follows the C++ rules for matching polymorphic overloads. Matches on explicit type arguments are done by counting the number of arguments. For implicit arguments, all candidates whose signatures unify with the call signature are collected, and then the most specific one (if unique) is chosen (even if there is a closer more general overload). The open-ness of the Felix model does make for some degree of fragility compared to the much more robust GCaml model, however the GCaml technique is considerably more verbose, and brevity and easy of naming is one of the arguments in favour of overloading. -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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