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: tub!wg@relay.EU.net (Wolfgang Grieskamp)
Newsgroups: comp.compilers
Subject: Re: Defining polymorphism vs. overloading
Keywords: design, polymorphism
Message-ID: <1771@opal.tubopal.UUCP>
Date: 6 Sep 90 02:16:05 GMT
References: <9008310419.AA06194@karakorum.berkeley.edu> <1990Sep2.220039.4966@rice.edu>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: tub!wg@relay.EU.net (Wolfgang Grieskamp)
Organization: Technical University of Berlin
Lines: 55
Approved: compilers@esegue.segue.boston.ma.us

wright@gefion.rice.edu (Andrew Wright) writes:

>C. Strachey originated the terms "ad-hoc" and "universal" polymorphism
>to distinguish these issues.  overloading is an example of ad-hoc
>polymorphism, automatic coercions such as real->int are another.

The unslightness of "ad-hoc" polymorphism may be one of the origins of the
confusion. In

	Wadler P, Blott S: How to make ad-hoc polymorphism less ad-hoc,
	Proc. 16th Symp. on Principles of Programming Languages (Jan.89),
	60-76

... the authors describe so-called "type-classes" (related, but not the same
as classes in object-oriented languages). This is just an approach, not
the ultimative solution, grew out of the efforts of the Haskell commitee
(a new generation functional language, based on ML and others). 

Regarding to the pragmatic points raised in the discussion, I guess what's
runtime, what's compile time, what's the same and what's another code is not
a sufficient classification. All this depends highly on the compiler's and 
target machine's architecture. For example, function *length* over lists may
or may not generate the same code, depending on the garbage collection
scheme (lists of primitive objects may be collected in another way than
lists of non-primitive objects). 

In object-oriented languages, the compiler may or may not derive the actual 
class of a message receiver - depending on the sender's context (and the 
compiler's capabilities), but not on the class declaration. So, is the same
message in one context overloaded, but in another polymorphic?

Even the square bracket operator in C may or may not generate different code.
If sizeof(int)=sizeof(long), then the square for a pointer to "int" will 
generate the same code as for a pointer to "long", otherwise not.

Returning to the mentioned paper, the actual problem sketched out there is
illustrated by the impossibility to define (in most languages)

	square(x) == x*x

... for any x (int, real, complex, etc.). The problem here is the "ad-hoc" 
polymorphism (or overloading) of "*". To say it in C, you cannot define

	swap(vec,i,j) void *vec; int i,j;
	{  void tmp; tmp = vec[i]; vec[i] = vec[j]; vec[j] = tmp;
	}

... for any vector vec. This shows clearly, that square brackets are the
worst-case - "ad-hoc" polymorphism (or overloading). The question seems to
me how to eliminate it.
[There was a PS on this message that got smashed in transmission.  Hope it
didn't say anything vital. -John]
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.