Re: Defining polymorphism vs. overloading

It is very difficult to draw a meaningful abstract distinction among
polymorphism, overloading and "generic functions" in the absence of
first-class procedures. After all, "polymorphism" is an attribute of
procedures, but if procedures don't _really_ exist in your language, you are
almost always going to be able to "fake" polymorphism by compile-time or
run-time analysis.


Indeed, this compiler fakery is just what's confusing most people. I can
write a program in which '+' is applied to pairs of 32-bit integers and to
pairs of complex numbers (user defined), and in a lot of language
implementations the compiler does some analysis and picks the code before
run-time. But suppose I assign the function denoted by '+' to a variable (as
in Lisp #'+), and then pass it through some code that makes it undecidable
what the type of x and y are in a subsequent call to 'x + y'. Overloading
ain't possible.


Now, polymorphism can be "supported" in a variety of ways by a language
implementation. An implementation could allow the user to give several
definitions of '+', and wrap them in type-checking code to yield the "real"
'+'.


In a language without first-class procedures you won't be able (without
peeking) to tell the difference between this method and a variety of run-time
dispatching schemes that never create a single '+' object.


Personally, I like to think of overloading (ad-hoc) and non-polymorophic run
time dispatching as compiler optimizations (constant-folding, really) of
polymorphism. Rather like in-lining once-called procedures. But I also
think that languages are much better off being founded on first-class
procedures and compiler optimizaton than some idea of "generic function".
(Flames to comp.lang misc.)


---
Chip Morris chip@soi.com
617-497-5054 ..!uupsi!soi!chip
Software Options, Inc., 22 Hilliard St., Cambridge, MA 02140
--

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