Re: Defining polymorphism vs. overloading

I've watched this discussion a little and have become confused by its intent.
Is this simply a round of "this is my idea of how polymorphism/overloading/
whatever ought to be defined"? Certainly Cardelli, Strachey, and others
had (have, if still alive) a clear idea of what they meant when they used the
words. I find Cardelli's definition illuminating as well. (I'm only loosely
familiar with others so I'm not really able to judge.) The notions are tied
to the types of objects, and the type signature of the operator or function.
They are not tied in any interesting way to when the functions do their thing,
whether at runtime or compile time.


In most languages, the operator "+" is considered overloaded (ad hoc
polymorphic) under this taxonomy, because different algorithms are required
for each of its possible uses. E.g., ADD is used for integer add, FADD for
floating point, etc. It is irrelevant that both use 32-bit arguments, and
therefore could conceptually operate on the same data. For x,y of type float
and i,j of type int:


x + y => FADD x,y


i + j => ADD i,j


x + i => CIF i,t
FADD x,t


and so forth. Although it is possible that the instruction


ADD x,y


could appear somewhere, it is questionable that this represents an add in
any real sense. It does not represent a floating point add, because it is
an integer operation. It does not represent an integer add, because it does
not have integer operands. At best it seems that it is a bit-pattern
transformation operation that might be interpreted in special ways, because
the types float and int are both specializations of the type bit-pattern.
In a traditional assembler language the only supported data types are bit-
patterns of various sizes, so in that context I suppose it makes some sense.


Under the same taxonomy, the function


define list_count = lambda list
if empty list then
0
else
1 + list_count ( tail list )
;


is (universal) polymorphic, because the same algorithm is used regardless of
the type of list. The compiler has the option of optimizing the code in a
certain way if the data types are suitable, but it does not have to be done,
and it does not fundamentally alter the nature of the beast. The operation of
the function is *independent* of the type of the function arguments.


If we look at the type signatures, we get


+ : int x int -> int
: int x float -> float
: float x float -> float
...


list_count : list *a -> int


There is just one type signature for list_count, which happens to involve a
type variable, *a.


I suppose that to some people words mean what they want them to mean, and I
have no problem with that. However, Cardelli's approach has advantages that
I can see (even with my limited understanding), and I guess I don't see how
some of these other proposals improve on it any.
--

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