English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [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: 2007-03-08 (23:51)
From: skaller <skaller@u...>
Subject: RE: [Caml-list] Operator overloading
On Thu, 2007-03-08 at 14:02 -0600, Robert Fischer wrote:

> When I see "+", I want to know what that means.  With operator overloading, I don't know. 

This argument is fallacious: When you see + you know it means addition
of whatever argument types are used.

Addition is well understood. The structure of the types is not

The problem is that Ocaml doesn't provide sufficiently powerful
system to easily encapsulate this structure.

Addition is a bad example because it's somewhat questionable.
It is clearer if we talk of map, fold, and other such operations
which are clearly polyadic operators.

Overloading eases the burden of a weakness in the language,
not providing polyadic map and fold.

In fact Ocaml functors just provide overloading, because they
only work for finite manual instantiations.

They don't provide genunine polyadic programming.

FISh 1 is a polyadic array programming language, you can
do algorithms which are independent of rank
(number of dimensions). In that language, map and fold
only need ONE definition and then work on all data types.

BOTH Ocaml functors and overloading are just hacks to
work around the lack of ability to properly express
higher order natural transformations.

C++ provides polyadic behaviour: the whole of STL
is based on it, it just doesn't do it the right way.

The thing to understand is that a lot of programming
is experimental and/or loose: a lot of code is actually
written in dynamically typed scripting languages.

For systems like Ocaml, you need a mix of sloppiness
and heavy typing, because unless you're implementing
a well understood mathematical formalism, too much
formality and abstraction just gets in the way.

For example if you were implementing a C++ compiler in Ocaml
I'm going to bet you'd want plenty of space to fiddle with
your representations and concepts, because you don't quite
know what it is you're actually implementing.

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net