Re: [Caml-list] Why are arithmetic functions not polymorph?

[John Max Skaller <skaller@ozemail.com.au>]

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