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-09 (12:46)
From: Jacques Carette <carette@m...>
Subject: Re: [Caml-list] Operator overloading
Andrej Bauer wrote:
> I will repeat my suggestion again: when writing serious and 
> complicated code, overloading can cause a lot of harm. When 
> manipulating expressions such as vectors and matrices interactively, 
> it is convenient to have overloaded + etc. Perhaps the right way to 
> solve the dilemma is to have a "toplevel on streoids" which 
> intelligently resolves ambiguities. The intelligence can then go much 
> further than simple overloading.

The (heavily typed) computer algebra system Axiom tried just this.  The 
end result was that, frequently, 90% of the computation time was spent 
in the "toplevel guesser", 10% on the actual computation.  Much worse 
was that while the underlying computations were very predictable (types 
help), the toplevel was so huge and complex, that it was unpredictable 
what *it* would do.  And, worse, lots and lots of "types" now resolved 
to the catch-all 'Expression' type.

Note however that Matlab also has its share of massive overloading, and 
yet it doesn't suffer as much as Mathematica does from this.  So there 
must be something about the richness of the available data-structures 
that makes the Matlab approach 'fail'.