From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA23319; Sat, 13 Apr 2002 17:36:06 +0200 (MET DST) 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 RAA16673 for ; Sat, 13 Apr 2002 17:36:05 +0200 (MET DST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g3DFa4r17544 for ; Sat, 13 Apr 2002 17:36:04 +0200 (MET DST) Received: from beertje.william.bogus (williamc.xs4all.nl [213.84.56.92]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g3DFa34S042045; Sat, 13 Apr 2002 17:36:03 +0200 (CEST) Received: (from williamc@localhost) by beertje.william.bogus (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g3DFVcf03030; Sat, 13 Apr 2002 17:31:38 +0200 X-Authentication-Warning: beertje.william.bogus: williamc set sender to williamc@paneris.org using -f From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15544.20312.792683.76557@beertje.william.bogus> Date: Sat, 13 Apr 2002 17:31:36 +0200 (CEST) To: caml-list@inria.fr Subject: Re: [Caml-list] operator overloading In-Reply-To: References: <15543.61656.841585.602588@beertje.william.bogus> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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