Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] operator overloading
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Rogoff <bpr@b...>
Subject: Re: [Caml-list] operator overloading
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