caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: William Chesters <williamc@paneris.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] operator overloading
Date: Sat, 13 Apr 2002 17:31:36 +0200 (CEST)	[thread overview]
Message-ID: <15544.20312.792683.76557@beertje.william.bogus> (raw)
In-Reply-To: <Pine.BSF.4.40.0204131340520.91623-100000@bpr.best.vwh.net>

Brian Rogoff writes:
 > > Do you really want overloading for this purpose?  If it's just for
 > > cosmetic purposes, like being able to write
 > >
 > >       z := A * x + y
 > >
 > > where x y z are vectors and A a matrix, then I for one am happy with
 > >
 > >       z |:=| A %*| x |+| y
 > >
 > > (where %*| means matrix-times-vector, etc.).
 > >
 > > At least you get to see what's really going on.
 > 
 > The whole point of abstraction is to forget about what's really going on.

Is it?

Sometimes, as with linear algebra, the point is just to express what's
going on more concisely and maintainably.

Sometimes the point is to leave what's really going on *undefined*,
e.g. using a functor.  It's precisely in this case that it's really
essential not to elide distinctions between operators, because that
will make it harder for people to recover "what is going to happen" in
any particular application.  I.e. they simply don't have the faintest
idea how or why your program actually works.  That's one of the
downsides of abstraction: it's all too easy to end up with a system
which is harder to maintain rather than easier, and with libraries
which have narrower applicablity (because they are very obscure)
rather than broader.

C++'s abstraction mechanism is wonderful on paper: it does the same as
ML functors but is actually efficient (if you use the right compiler).
In practice, though, it's awfully hard to do anything ambitious with
it, because you can't specify signatures and because there are too
many opportunities for ambiguity, so that you end up with an unwieldy
mess which it's impossible for the reader to "find an end of" and
begin unravelling.  If ocaml could inline functors it would be a much
better vehicle for building abstract numerical libraries than C++.
The fact that it _doesn't_ have overloading and _does_ force you to
specify everything transparently is a strength, not a weakness, to my
mind.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2002-04-13 15:36 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-12 19:08 Issac Trotts
2002-04-13  8:48 ` William Chesters
2002-04-13 13:58   ` Brian Rogoff
2002-04-13 15:31     ` William Chesters [this message]
2002-04-14  3:10       ` Brian Rogoff
2002-04-13  9:00 ` Daniel de Rauglaudre
2002-04-13 21:35 ` Johan Georg Granström
2002-04-14  1:50   ` Jacques Garrigue
2002-04-15 16:22 ` Jun P.FURUSE
2002-04-13  1:32 Gurr, David (MED, self)
2002-04-13  5:26 Issac Trotts
2002-04-13  8:43 forsyth
2002-04-14  4:15 Issac Trotts
2002-04-15 17:05 Issac Trotts
2007-03-08 14:41 [Caml-list] F# Robert Fischer
2007-03-08 17:30 ` Roland Zumkeller
2007-03-08 17:54   ` Brian Hurt
2007-03-08 19:40     ` [Caml-list] Operator overloading Jon Harrop
2007-03-08 20:44       ` Brian Hurt
2007-03-08 22:24       ` Fernando Alegre
2007-03-08 20:02 Robert Fischer
2007-03-08 20:15 ` Michael Hicks
2007-03-08 20:50   ` Brian Hurt
2007-03-08 21:05 ` Tom
2007-03-08 21:31   ` Brian Hurt
2007-03-08 22:09     ` Michael Vanier
2007-03-08 22:34     ` Till Varoquaux
2007-03-09 16:02       ` Brian Hurt
2007-03-10  3:23         ` skaller
2007-03-08 22:14   ` Ian Zimmerman
2007-03-09 10:29     ` Jon Harrop
2007-03-09 16:28       ` Ian Zimmerman
2007-03-08 23:51 ` skaller
2007-03-09  7:23   ` Tom
2007-03-09  9:24     ` skaller
2007-03-09  9:32       ` Tom
2007-03-09 10:00         ` skaller
2007-03-09 10:14         ` Jon Harrop
2007-03-09 10:38   ` Jon Harrop
2007-03-09 10:20 ` Jon Harrop
2007-03-09 12:08 ` Andrej Bauer
2007-03-09 12:48   ` Jacques Carette
2007-03-09 13:24   ` Andreas Rossberg
2007-03-10  5:08   ` Daniel Andor
2007-03-10  5:33     ` David Thomas
2007-03-08 23:20 Robert Fischer
2007-03-09 10:31 ` Jon Harrop
2007-03-09  7:36 oleg
2007-03-09 11:09 ` [Caml-list] " skaller
2007-03-09 13:52   ` Andreas Rossberg
2007-03-09 15:07     ` skaller
2007-03-09 16:28       ` Andreas Rossberg
2007-03-10  3:13         ` skaller
2007-03-09 16:40 Robert Fischer
2007-03-09 17:25 ` Jon Harrop

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=15544.20312.792683.76557@beertje.william.bogus \
    --to=williamc@paneris.org \
    --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).