[M3devel] operator overloading?

[Rodney M. Bates]

Jay K wrote:
> 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.
> 

That is one of the ways that would greatly simplify the semantics.
It would also make it more difficult for programmers to define
operator meanings with no resemblance to traditional mathematical
meanings of the operators, which I regard as really bad practice,
but is encouraged by the overloading systems I know about.

> 
> No implicit conversions.
>   (I do think some conversions are ok, integers to wider integers, but 
> nobody else agrees.)

We already have something far better than implied conversions.  We have
assignability, which, simplified, says that in a lot of assignment-like
contexts, what is needed is that the RHS _value_ must be a member of the
LHS's _type_.  The types are not necessarily disjoint, so there are lots
of cases where this accomplishes something.  Enforcing this requires a
mix of static and runtime rules.  Obviously, if the RHS type is disjoint
with the LHS type, that is statically know to be illegal.

When it's legally assignable, Modula-3 doesn't call it a type conversion.
This is higher-level and more abstract.  There may well be an implied
_representation_ conversion, for example, different sizes of integers.
Most (all?) other languages require that every different machine-level
representation be a different type, and this creates a need for
programmer-awareness of lots more type conversions, implicit or explicit,
than the Modula-3 approach

We didn't get assignability between INTEGER and LONGINT, but we have
it between a base ordinal type and all its subranges and all their
packed types (subject to value inclusion.) as well as several other
cases.

> Isn't that much simpler than any other language does it?

I think it can be a lot simpler than any other language.  There is
still a _lot_ of unanticipated detail.

> 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?
> 

I can think of another visibility rule, but it derives from other things
I would have to describe first.

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

Yes, I would strongly support that rule.  (Did you know Ada does not?)

> 
> 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).
> 

I think exception raising can be kept orthogonal to operator overloading by
defining an operator expression (once resolved to a single function) as
equivalent to an ordinary call.  In fact, everything except determining
what function is to be called can be defined by an equivalence to an
ordinary call of that function.

> 
>  - 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
>  > >
>  > >
>  > >
>  > >