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

[Brian Hurt <brian.hurt@qlogic.com>]

On Fri, 23 May 2003 brogoff@speakeasy.net wrote:

> I understand the difference between operator redefinition, which OCaml and 
> SML have, and user defined overloading, which neither has, but which can be 
> found in Haskell and Clean (sort of, through type classes) and C++ and Ada. 
> 
> 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. 
> It gracefully handles the most important, very simple cases, and sneaks 
> in the ability to type a much wider range of functions than can be typed now. 
> You should at least take a look at the README in the prototype to get an idea of 
> what I mean here. 

OK.  I'm reading the readme.  First off, congratulations, you're dodging a 
lot of the bullets that C++ didn't.  

Here's a question.  Consider the following code:

generic one = | int => 1 | float => 1.0

generic two = | int => 2 | float => 2.0

generic plus = | int -> int -> int = (+)
               | float -> float -> float = (+.)

plus one two;;

What's the result?  Is it the int 3, or the float 3.0?

Another problem already arises with the generic (aka overloaded)  
comparisons- you oftentimes need to arbitrarily specify types in order to
replace the expensive call to the generic compare with a much cheaper
inlined type-specific compare.  If you start having to specify types a lot 
more often, that reduces the advantage of having type inference.

> New operators are not sufficient, and SML is more powerful in it's ability to 
> define new operators than OCaml (minus CamlP4) is. 

Yeah- I'd like to be able to define accessor operators somehow.  Say being
able to define $[ ] as hashtbl lookups, so that h$[3] ==> Hashtbl.find h
3.

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