[M3devel] operator overloading?

[Jay K]

Rodney, what if the signatures of overloaded operators is "fixed".
That is + can only take two T's and return one T.
< can only take two T's and return one boolean.


No implicit conversions.
  (I do think some conversions are ok, integers to wider integers, but nobody else agrees.)
Isn't that much simpler than any other language does it?
Are the rules still hard to understand?
  (And I believe this is still fairly valuable.)


Furthermore, something like, maybe, the operators may only be defined in the interface that declares T?
Or maybe, the operators are always available on all types, but you get a link error if they weren't defined?


And of course, you can't define them for builtin types. They are already defined.


And, I realize, there is a question of errors.
+ can fail.
The interface would have to that they raise exceptions.
You could have something like FPU.i3 custom per type to control it. The compiler
wouldn't know about this (except maybe for builtin LONGINT).


 - Jay


> Date: Sun, 21 Nov 2010 13:52:08 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] operator overloading?
> 
> I've been around that block too many times with Ada and C++.  Programmer-
> defined overloading (either operator and/or function name) is a semantic
> disaster.  It interacts with stuff all over the language, and the complexity
> just explodes.  I have spent several years of my life having to learn every
> in and out and dark corner of overloading and all its fallout in Ada, both
> to implement it and to try to help working programmers cope with it. I can
> say with complete confidence that Ada would be half the size/complexity
> it is, without it.
> 
> Moreover, hard as it is for a compiler writer or language lawyer to understand
> it, it is even worse for the everyday programmer.  Again, I can testify that
> almost nobody (the above types excepted) comes anywhere close to understanding
> the rules.  They don't even want to try.  Their eyes glaze over, and they just
> want you to tell them how to code such-and-such so it will compile and call
> the function they want it to.  For the future, all they want is restrictive
> but simple programming guidelines on things to avoid unconditionally, so they
> won't keep getting burned again and again.
> 
> C++'s take on overloading is simpler in some respects, more complicated in
> others, but overall, quite a bit worse and, I dare say, much poorer-understood
> by working programmers.
> 
> The upshot is that the (mis)feature of programmer-defined overloading is mostly
> used only in degenerate and trivial ways.  This, of course, raises the question
> what good is it when: 1) it makes programming more difficult, 2) programmers
> avoid most of it anyway, and 3) even so, it results in lots of code that
> programmers just barely hope they understand the meaning of what they wrote.
> The latter is a *very* big deal in quality of released code.  And I didn't even
> mention the added difficulty in implementing the language.
> 
> I do realize that function call notation can be a lot harder to read (and write)
> than operator notation in a few situations.  I've also been around that block more
> times than one, in fact quite recently.
> 
> I have many times mused over whether it would be possible to add something that
> would give the most important benefits and not be a complete semantic train wreck.
> Sometimes I think it could be done a lot better than we have seen, but at best,
> it would be a significant semantic complication, even if restricted to operators
> only.
> 
> In Modula-3, we have a language whose most distinctive characteristic is an
> exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other
> language that comes close by this criterion.  We need to preserve that.
> 
> Rodney Bates
> 
> 
> Jay K wrote:
> > Is it really so difficult to add operator overloading to the language?
> > 
> >  From a user's point of view, I know it is very useful in certain 
> > situations.
> > 
> > 
> >  - Jay
> > 
> > 
> > 
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101121/cbaaa5d3/attachment-0002.html>