Re: Polymorphism vs. Overloading

mmcg@bruce.cs.monash.edu.au (Mike Mc Gaughey)
Sat, 29 Oct 1994 03:48:44 GMT

          From comp.compilers

Related articles
[19 earlier articles]
Re: Polymorphism vs. Overloading dekker@dutiag.twi.tudelft.nl (1994-10-31)
Re: Polymorphism vs. Overloading danhicks@aol.com (1994-10-31)
Re: Polymorphism vs. Overloading odersky@ira.uka.de (Martin Odersky) (1994-10-31)
Re: Polymorphism vs. Overloading bevan@cs.man.ac.uk (1994-10-27)
Re: Polymorphism vs. Overloading pjj@cs.man.ac.uk (1994-10-28)
Re: Polymorphism vs. Overloading jhf@c3serve.c3.lanl.gov (1994-10-28)
Re: Polymorphism vs. Overloading mmcg@bruce.cs.monash.edu.au (1994-10-29)
Re: Polymorphism vs. Overloading hbaker@netcom.com (1994-10-29)
Re: Polymorphism vs. Overloading jhallen@world.std.com (1994-11-01)
Re: Polymorphism vs. Overloading kanze@lts.sel.alcatel.de (kanze) (1994-11-01)
Re: Polymorphism vs. Overloading davidm@Rational.COM (1994-10-31)
Re: Polymorphism vs. Overloading bill@amber.ssd.csd.harris.com (1994-11-01)
Re: Polymorphism vs. Overloading drichter@pygmy.owlnet.rice.edu (1994-11-01)
[5 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: mmcg@bruce.cs.monash.edu.au (Mike Mc Gaughey)
Keywords: polymorphism
Organization: Computer Science, Monash University, Australia
References: 94-10-144 94-10-180
Date: Sat, 29 Oct 1994 03:48:44 GMT

ryer@dsd.camb.inmet.com (Mike Ryer) writes:
>Overloading happens at compilation time -- the compiler decides which function
>to invoke based on statically-determined types of the operands.


>Polymorphism may not happen until runtime -- the compiler generates code that
>fans out based on the runtime value of a tag.


Wow - three posts all claiming polymorphism happens at runtime :)


Overloading was identified (by Strachey?) as `ad-hoc polymorphism'; the
idea was that if functions of the same name could exhibit very different
behaviours at different argument types, they were overloaded. The obvious
example is `+' applied to integer or real arguments - they require different
machine code.


He also identified `parametric polymorphism' as the class of functions
whose behaviour is specified in some uniform way over some class of
objects (eg: lists of <anything>); other people (eg. Cardelli) have
called this `generic polymorphism'. The basic requirement here is
that although the types of *some* parts of the objects provided as
parameters may be unknown, the function in question doesn't need to
examine those parts of an object to operate correctly (that's why
it doesn't care about their types).


There is no requirement for tags to support this at runtime in a
strongly statically typed language; all that is required is that the
generated code be capable of processing the elements of all types that
satisfy the assumptions of the given set of types.


Two common examples of this: object oriented languages with single
inheritance can simply lay out the inherited (supertype) part of the
object as a prefix to the rest of the object. Polymorphic functional
languages can (and do!) rely on the assumption that all polymorphic
items are just pointers to the heap, and hence have the same size and
copying semantics (which is sufficient, assuming you don't have a
`polymorphic' equality operator). Modulo some current difficulties
with garbage collection, this allows them to be implemented without
tags. In fact, until recently it was *overloading* in functional
languages which used the tags; parametrically polymorphic functions
never examine type tags on data.


In C++, all `polymorphism' is actually treated as overloading - and is
compiled that way, by generating seperate concrete code sequences for the
different instances of templated classes, and resolving the actual
calls at link time.


Thus, the precise time at which `type resolution' happens is very much
an implementation issue; the meaning of `polymorphic' really *includes*
overloading as a subclass.


Cheers,


        Mike.
--
Mike McGaughey AARNET: mmcg@bruce.cs.monash.edu.au
--


Post a followup to this message

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