Overloading and type-safeness

maniattb@cs.rpi.edu - in real life Bill Maniatty wrote:
  If operator overloading could be made type safe (I'm not
  saying that it can't, but I'm just not sure how, replies are welcome here)


In an explicitly typed language without implicit coercion (ie where all
coercions are explicit) operator overloading is safe unless there are
operators with the same parameter types, same names, and different result
types; even that case of unsafeness depends, of course, on the language
being able to deliver results which are not explicitly typed (some
interactive - calculator style - languages do this; otherwise a much
stronger statement about the safeness of overloading in explicitly typed
languages could be made).


With implicit coercion the situation is somewhat more difficult. Even
here, it is in general possible to make overloading type safe by imposing
some very simple restrictions (both type safe and unambiguous),
particularly if the only coercions involved are subtype/supertype
coercions.


The problems tend to arise when undisciplined use of overloading leads to
ambiguity; for example, division in the reals is not an extension of
division in the integers, so using the same symbol for both in the
presence of subtype polymorphism in a form which counts integers as reals
can lead to problems. Some languages have this problem - but it's a
problem of letting implicit (subtype/supertype) coercions get out of hand,
not a problem with overloading.


To put it simple: there is no reason why, with decent language design,
operator overloading should not be type safe.


The example Bill Maniatty gives of one programmer using "<=" to be a test
on cardinality and another using it for a test of the subset relationship
has nothing to do with overloading. If two programmers write two programs
and just happen to use the same identifier for two different things it
doesn't matter at all whether those things are operators, functions,
procedures, data values, or something else; merging the two programs in
such a way that the scopes or the two (identical) identifiers overlap will
create problems. (This is one reason why it's easier to combine chunks of
single assignment languages than chunks of other languages: if you give
two distinct definitions with the same scope the compiler will notice!)
Compilers will use type differentiation to disambiguate in some cases, and
if overloading allows them to do so successfully that's all to the good;
if the identifier has the same type in both programs, as in the "<="
example, it doesn't matter whether overloading is present or not - the
problem is one of conflicting definitions of the same type, which is not
permitted by overloading anyway.


Tom Thomson [ tom@fiveg.icl.co.uk
--

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