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
generic functions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-01-09 (18:09)
From: brogoff <brogoff@s...>
Subject: Re: [Caml-list] generic functions
On Sun, 9 Jan 2005, David McClain wrote:
(unsnipped from Brian Hurt, don't remove quoted attributions if you don't
 want your name misattributed ;)
> > With the exception of certain artificial contests (Paul Graham) I've never
> > met a real world problem that needed overloading, or even benefitted
> > signifigantly from overloading that didn't benefit just as much or more
> > from one of the solutions above.

Our experiences differ significantly then. I'd say that overloading is a
benefit in many "real world" cases, and that type inference is largely
unnecessary (to be more precise, it's useful for small helper functions,
otherwise, the type (scheme) is useful documentation) and in fact in
that now old ML2000 proposal type inference was under question. Yes, I read
the  original ML discussion about why it was wanted in theorem provers and
all that, but I'm not convinced.

All of the workarounds you mention are ugly workarounds, IMO. I'm not trying to
open this perennial argument again, since I believe it's been proven that no
one has ever changed their mind on account of internet email or usenet
postings, just to make it clear to anyone asking that the opinion epressed
doesn't have unanimous support.

> I would mention ad-hoc, interactive, engineering computing, e.g., NML,
> Mathematica, MatLab, where generic functions and overloading are extremely
> useful. But none of these languages can produce safe code, and I would never
> recommend using any of them for production releases of software. OCaml =
> strong safety. NML and others = fast interactive exploratory programming,
> but not safe.

That's because these languages (don't know about NML) and CLOS are at best
dynamically typed, not because they have overloading. And you have to define
"unsafe" in a special way, dynamically typed garbage collected languages
shouldn't seg fault, but you may get run time errors, as you can with ML. Once
again, I know what you mean, and ML is by some measure "safer", but I don't
think it fair to lump Lisps or Mathematica with unsafe languages.

-- Brian