caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: brogoff <brogoff@speakeasy.net>
To: caml-list@inria.fr
Subject: Re: [Caml-list] generic functions
Date: Sun, 9 Jan 2005 10:09:14 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0501090946160.31500@shell3.speakeasy.net> (raw)
In-Reply-To: <001901c4f66f$3370f4e0$0401000a@dylan>

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


  reply	other threads:[~2005-01-09 18:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-09 13:19 wiedergaenger
2005-01-09 14:56 ` [Caml-list] " Richard Jones
2005-01-09 15:48 ` Brian Hurt
2005-01-09 17:17   ` David McClain
2005-01-09 18:09     ` brogoff [this message]
2005-01-09 18:45   ` padiolea
2005-01-10  0:23   ` skaller
2005-01-11 12:14     ` Daniel Yokomizo
2005-01-10  9:55   ` [Caml-list] " Alex Baretta
2005-01-10 10:47     ` Olivier Andrieu
2005-01-10 12:16       ` Alex Baretta
2005-01-12 23:49     ` Aleksey Nogin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0501090946160.31500@shell3.speakeasy.net \
    --to=brogoff@speakeasy.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).