Dialects, C++, Overloading

[Herman Rubin]

In article <5137:06:46:38 at stealth.acf.nyu.edu>, brnstnd at stealth.acf.nyu.edu writes:
> Rob, the issue is not user-defined operator syntax. The issue is overloading.
> 
> Say a language provides a vector library with a vector addition routine.
> You might write ``a = b + c'' in full as ``a = b vec.+ c''. Overloading
> means abbreviating vec.+ and string.+ and matrix.+ and complex.+ as a
> single operator. We're not asking you to write a = vec.plus(b,c); we're
> pointing out the problems of ambiguous abbreviation.

In the same line of reasoning, one should have "a = b long.+ c", and
similarly for byte, short, etc.  I am not saying we should not have
these, in fact we should when we want to override type defaults.  But
as long as an operator is well-defined for a given set of types for its
arguments, I do not see any real problems.  The type-override operations
are likely to be machine dependent.  However, as Dan states, this
situation is self-flagging..

> My main concern is maintainability. I hate debugging Ada---particularly
> someone else's Ada---because I have to learn an entirely new language
> just to understand each program. I have to force myself to look
> suspiciously at each operator and function call, asking ``what are the
> types?'' and ``is it overloaded?'' If I don't read Ada so painfully, I'm
> liable to overlook an overloaded operator, automatically assuming that
> (for example) a = b + c has no side effects or that bar(x) + foo(y) is
> the same construction that I just debugged when I saw it in the last
> routine.

To require that a program be maintainable by someone who does not understand
what the program is doing may be desirable, but not at the expense of making
it difficult to produce good programs in the first place.  Mathematicians are
quite used to extremely overloaded operators and terminology.  Clarification
of such problems should be in comments.

> I often have a lot of trouble finding the definition of an overloaded
> function---my searching tools are of no help when the syntax sucks and
> the definition could be in any of ten libraries. But this is only a
> lesser evil compared to an overloaded operator insidiously taking over
> the innocent plus sign while the programmer looks away.
> 
| > If instead we make
| > the much more reassuring assumption that the programmer knows about the things
| > he is programming, then we have a second set of conventions to deal with:
| > those of the subject at hand.
> 
> This is the root of the problem: you have to learn a new language just
> to read each new program. When that new language doesn't even have the
> same semantics for a = b, the reader is in big trouble. In contrast, if
> overloaded functions and operators had to have a special syntax, they'd
> be an easy-to-notice, natural first spot to look for bugs. The special
> syntax doesn't have to be anything more than, e.g., an initial period;
> but it has to be there. If the language provided a standard way to
> expand all overloaded operators into unambiguous versions, life would
> be wonderful.

It is possible for an operator to be changed in "standard" situations if
one is not careful.  I have used an assembler which allowed this.  Possibly
a block could be put in for this purpose; I did not think it was a good
idea there.

It seems that both of the preceding posters would not object to new operator
symbols, or symbol strings.  This certainly will help.

I have broadened the posting of this followup, and because of the general
nature of the problem, I am directing followups to comp.lang.misc.

> ---Dan


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)