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-10 (05:08)
From: Daniel Andor <danielandor@g...>
Subject: Re: [Caml-list] Operator overloading
On 3/9/07, Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si> wrote:
> To all who like overloading, I dearly suggest that they explain to
> themselves the following bit of Mathematica:
> In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});
> In[2]:= f[{0,0}]
> Out[2]= {{0, 0}, {1, 1}}

If you define the function f as most people would expect a function to work,
and the way you would be taught in Mathematica to define a function, and the
way you define 95% of your functions, you get the expected answer:

In[1]:= f[v_] := {{1,0}, {1,1}} . (v + {0,1});

In[2]:= f[{0,0}]

Out[2]= {0, 1}

So I think you are a little disingenuous in your example... ;)

Lots of interesting and sophisticated reasons have been given for the pros
and cons of overloading.  As someone who programs numerical code on a daily
basis, I would just like to make a practical comment:

A reason to appreciate strong typing (and inference that makes it brief) is
that it catches a good number of bugs.  When programming mathematical
algorithms, not having overloading increases the complexity of the code and
hence introduces bugs.  Why?  Most mathematicians I know syntax highlight
with their eyes.  Complexity thwarts this process.  (Until you have a
programming language that checks the algorithm as well as computes it, this
human syntax highlighter is the best (well, only) thing you've got.)

I do occasionally get caught by the kind of error that Andrej mentions.  But
nonetheless I still reach for Mathematica, because algorithmic correctness
(which depends on my interaction with the computer) is at least as important
to me as type safety.

You know, if efficiency didn't matter, then we could all still prove our
programs with pencil and paper and then program it in assembler (or

Can't there be a systematic way of doing this overloading that will not
upset people while allow me (and Jon?) to `see' clearly?  There's got to be
a way!  :)