From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 76934BB91 for ; Sun, 9 Jan 2005 19:09:18 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j09I9I5E000673 for ; Sun, 9 Jan 2005 19:09:18 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA22593 for ; Sun, 9 Jan 2005 19:09:17 +0100 (MET) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j09I9FYS031942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Jan 2005 19:09:17 +0100 Received: (qmail 30987 invoked from network); 9 Jan 2005 18:09:14 -0000 Received: from shell3.speakeasy.net ([69.17.110.72]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Jan 2005 18:09:14 -0000 Date: Sun, 9 Jan 2005 10:09:14 -0800 (PST) From: brogoff To: caml-list@inria.fr Subject: Re: [Caml-list] generic functions In-Reply-To: <001901c4f66f$3370f4e0$0401000a@dylan> Message-ID: References: <001901c4f66f$3370f4e0$0401000a@dylan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 41E1734E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41E1734B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 overloading:01 overloading:01 inference:01 inference:01 workarounds:01 workarounds:01 ad-hoc:01 ocaml:01 clos:01 garbage:01 speakeasy:01 exception:01 theorem:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: 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