Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!ico!haddock!ima!esegue!compilers-sender
From: pase@orville.nas.nasa.gov (Douglas M. Pase)
Newsgroups: comp.compilers
Subject: Re: Defining polymorphism vs. overloading
Keywords: polymorphism
Message-ID: <8133@amelia.nas.nasa.gov>
Date: 6 Sep 90 00:04:42 GMT
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: pase@orville.nas.nasa.gov (Douglas M. Pase)
Organization: NASA Ames Research Center, Moffett Field, CA
Lines: 71
Approved: compilers@esegue.segue.boston.ma.us

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.
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.