caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Robert Fischer" <RFischer@RoomAndBoard.com>
To: <caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] Operator overloading
Date: Thu, 8 Mar 2007 14:02:21 -0600	[thread overview]
Message-ID: <3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB74@selma.roomandboard.com> (raw)

> For example, I often define +| for vectors, +|| for matrices, *| for 
> scalar-matrix multiplication, *|| for vector-matrix and *||| for 
> matrix-matrix. I also want to support complex numbers and symbolic 
> expressions and I don't particularly want to remember and document 50 numeric 
> operators, nor explain their existence to my customers...
>
Which is exactly my point.  You should have to document all that, because they are genuinely different operations.  You have these operations, so why shouldn't you document them?  Or, better yet, abstract them and organize them.  By using operator overloading, you're sweeping under the rug genuine complexity -- something that my surprise later developers!

When I see "+", I want to know what that means.  With operator overloading, I don't know.  An IDE might help me out there, but that's just polishing a genuine ding on code readbility and maintainability.  Why should I have to rely on an IDE to make sense of my code?

If I have a typing issue in my code, I want the compiler balk at where the problem is.  The best I can hope for with operator overloading is that the result type is caught through a failure of duck typing shortly down the pipeline -- but that very safety would is undermined if "down the pipeline" also uses lots of operator overloading.

I'm very sure that you can code with operator overloading and be productive.  The person writing the code probably even feels like it's a productivity and readability boon.  But I see maintainability as a big problem here.  As far as I'm concerned, if two things do different things, they should have different names.  You can give them funny names like "+|", but it should still be different names.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Thursday, March 08, 2007 1:41 PM
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading


On Thursday 08 March 2007 17:54, Brian Hurt wrote:
> Roland Zumkeller wrote:
> > Wasn't there a more or less good reason for OCaml *not* to support
> > operator overloading?
>
> Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy,
> it'd be really nice to use operator overloading here", you should use a
> module and a functor instead.
> ...

For me, operator overloading is about clarity. In the absence of operator 
overloading, you cannot regain the lost clarity using modules and functors.

This is one of the two things I missed when I moved from C++ to OCaml: 
operator overloading and template metaprogramming for low-dimensional vector 
and matrix operations. The latter can be addressed by autogenerating code. 
The former cannot be addressed in the current OCaml.

For example, I often define +| for vectors, +|| for matrices, *| for 
scalar-matrix multiplication, *|| for vector-matrix and *||| for 
matrix-matrix. I also want to support complex numbers and symbolic 
expressions and I don't particularly want to remember and document 50 numeric 
operators, nor explain their existence to my customers and I certainly don't 
appreciate reading expressions written in this syntax.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


             reply	other threads:[~2007-03-08 20:02 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-08 20:02 Robert Fischer [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2007-03-09 16:40 Robert Fischer
2007-03-09 17:25 ` 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-08 23:20 Robert Fischer
2007-03-09 10:31 ` Jon Harrop
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
2002-04-15 17:05 [Caml-list] operator overloading Issac Trotts
2002-04-14  4:15 Issac Trotts
2002-04-13  8:43 forsyth
2002-04-13  5:26 Issac Trotts
2002-04-13  1:32 Gurr, David (MED, self)
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
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

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=3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB74@selma.roomandboard.com \
    --to=rfischer@roomandboard.com \
    --cc=caml-list@yquem.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).