Re: Defining polymorphism vs. overloading

tub!wg@relay.EU.net (Wolfgang Grieskamp)
6 Sep 90 02:16:05 GMT

          From comp.compilers

Related articles
[4 earlier articles]
Re: Defining polymorphism vs. overloading hrubin@l.cc.purdue.edu (1990-09-03)
Re: Defining polymorphism vs. overloading px@fctunl.rccn.pt (1990-09-03)
Re: Defining polymorphism vs. overloading plph@caen.engin.umich.edu (1990-09-03)
Re: Defining polymorphism vs. overloading daveg@near.cs.caltech.edu (1990-09-03)
Re: Defining polymorphism vs. overloading dmw9q@uvacs.cs.Virginia.EDU (1990-09-05)
Re: Defining polymorphism vs. overloading pase@orville.nas.nasa.gov (1990-09-06)
Re: Defining polymorphism vs. overloading tub!wg@relay.EU.net (1990-09-06)
Re: Defining polymorphism vs. overloading pase@orville.nas.nasa.gov (Douglas M. Pase) (1990-09-06)
Re: Defining polymorphism vs. overloading ok@goanna.cs.rmit.OZ.AU (1990-09-07)
Re: Defining polymorphism vs. overloading pardo@cs.washington.edu (1990-09-07)
Re: Defining polymorphism vs. overloading pardo@cs.washington.edu (1990-09-07)
Re: Defining polymorphism vs. overloading mmengel@cuuxb.ATT.COM (1990-09-11)
Re: Defining polymorphism vs. overloading freek@fwi.uva.nl (1990-09-10)
[6 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: tub!wg@relay.EU.net (Wolfgang Grieskamp)
Keywords: design, polymorphism
Organization: Technical University of Berlin
References: <9008310419.AA06194@karakorum.berkeley.edu> <1990Sep2.220039.4966@rice.edu>
Date: 6 Sep 90 02:16:05 GMT

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]
--


Post a followup to this message

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