Re: Definable operators

Craig Burley <burley@tweedledumb.cygnus.com> asks:
> Exactly _where_ do we disagree? ...


Well your last paragraph says it all...


> Until we get away from seeing technical stupid-pet-trick stuff like
> operator overloading as our salvation, we won't focus (as an
> industry) on solving the real problems, which involve human factors
> engineering, linguistic ergonomics -- basically, giving people
> languages that let them say what they _know_ about their programming
> problem, then _separately_ specify, where necessary, how to
> translate those expressions into solutions (such as
> implementations). Operator overloading is one of several serious
> rat-holes we've gone down while bumbling towards the goal. --


Operator overloading is NOT about lazy typing as you suggest. It is
not a "technical stupid-pet-trick". It is a powerful tool to reduce
the apparent complexity of a problem as I first argued. I refuse to
acknowledge any difference in principle between overloading a + b, add
(a, b) or a.add(b) yet earlier you defend overloading of itself. C++
may make a pig's ear of it but the language is an abomination that I
would never defend anyway. Algol 68 requires operators to be
type-unambiguous. Fortran 90 requires operators to take intent(in)
arguments but of course as with most modern imperative languages I can
pass a read-only pointer and modify an indirected value. Haskell with
one of the more powerful forms of overloading around is *functional*
so most of your arguments fly out of the window. There is little
doubt in my mind that functional programming is more 'proper' than
imperative programming, yet I am not yet ready to trade in Algol 68
for Haskell because in this age imperative techniques are still too
damned useful to let go of.


Fortran 90 also allows the programmer to specify *where* an operator
has been acquired from, e.g., use operator(+) from linear_operators
(OK you can't specify which version, but that could easily be repaired
- the RS Algol 68 compiler did so in the 70s, but is not much of a
problem anyway with well designed modules). I have argued in the past
that both sides of a module contract, export and import, should be
specifed explicitly. You must also bare in mind that the requirements
of prototyping and delivering production code are quite different and
I and others have argued in the past for a tiered language where some
features are deleted in production code (e.g., default public in F90).


I could give a detailed riposte to many of your other points, but I
will spare our other readers and lump them into one more point:
overloaded operators must be part of a well balanced language and
should not be used inappropriately (and this is the programmer's
decision really). Yes you can provide int8 by use of overloaded
operators when only int32 is provided (and in such a language, if you
really need the facility, then the type and operators do define
explicitly the behaviour) but clearly this should be supplied by other
aspects of the language (see Ada for the most comprehensive attempt at
sorting this out).


Where we agree is that there is still plenty of distance to cover in
the software engineering effort. I suspect that you have been stung
badly by C++ and are now reacting against all the tools that had
blades sharp enough to cut you thinking instead to put guards around
them. Fine, but do remember to leave some utility in the remaining
tool. Training to use a tool safely is as important as training to use
the tool for its purpose. I still prefer to leave such decisions in
the hands of the humans - coding standards, project managers, peer
code review, etc., while you are after the same kind of technical fix
that you deplore when used to increase the expressivity of a language.


I prefer to leave the language itself as simple as can achieve the
desired utility rather than burdening it with protective mechanisms
for one main reason: languages are devised by humans and are
themselves flawed, the larger the language, the more potential
interactions unexpected by the designers and worse by the
users. Fortran 90 and C++ are both appalling languages from my point
of view as the programmer's conception of how the language works
usually differs radically from the designers and the
specification. Algol 68 for all its flaws succeeds by economy of
design.


Cheers,
----------------------------------------------------------------------
Dave Lloyd mailto:Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd http://www.occl-cam.demon.co.uk/
Cambridge, England http://www.chaos.org.uk/~dave/
--

Return to the comp.compilers page.
Search the comp.compilers archives again.