🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2879

Re: Runtime Polymorphism -- To Have and Have Not

#2879
From: David Gudeman
Date: Sat, 02 Mar 1991 23:37
75 lines
3456 bytes
In article  <1991Mar2.002608.20387@engage.enet.dec.com> grier@marx.enet.dec.com writes:
]In article <559@coatimundi.cs.arizona.edu>, gudeman@cs.arizona.edu
](David Gudeman) writes:
]
]|> Runtime polymorphism (or runtime typing, or dynamic typing) means that
]|> identifiers in a language do not have types that are fixed at compile
]|> time,...
]
]   Not necessarily...

You can't answer "not necessarily" to a definition.  The above was a
definition of "runtime polymorphism" as I planned to use it later.
All of your comments that are made to a different definition of
"runtime polymorphism" are therefore 

]   Your comments seem to apply more to weakly typed systems
]rather than systems which include polymorphism and late binding.
]Is this perhaps what you meant?

I meant what I said.  You can introduce a different term with the same
definition if you want, but I don't see what it accomplishes.

]|> Another advantage of runtime polymorphism is code generality...
]|> <more deleted>
]
]   This has little to do with runtime polymorphism.  Ada generics,
]CLU and Trellis type generators and C++ templates all provide for
]generation of generic modules of code.

I don't know about CLU and Trellis, but Ada and C++ both have
painfully inadequate support for this -- at least when compared to
languages with runtime polymorphism.

  Of the three, only Trellis
]has late binding.  (It's coming back to me...  CLU has the REFANY
]type, but the CLU equivalent of type_case has to be applied to
]it to a particular type before applying any operations except
]assignment to it...)

]|> There are two problems with runtime typing (or I should say, one
]|> problem and one complaint of questionable importance)  First, it is
]|> very hard to make these programs run fast.

]   With respect to polymorphism and late binding, wrong.  A good
]compiler with strong typing and enough information can generate
]code which is just as good.

Well then, your definition of "late binding" is not equivalent to my
definition of runtime polymorphism.  Given a function read() that
reads stdin and returns a float or an integer, depending on what the
next token looks like, how do you generate code for

  x + read()

that is as efficient as addition in a statically typed langauge?  You
can't.  You need to test the return type of read() at runtime.

]   Aha!  We are talking about weak typing vs. strong typing!

Depends on your definition of weak typing.  If it matches my
definition of runtime polymorphism, then that's what I'm talking
about.

]   No flames here!  I just think that either you were using the wrong
]terminology, or hadn't realized that we have the technology to do these
]things right.

How can my terminology be wrong when I invented it myself?  And yes, I
know that the technology exists to do these things right -- it is done
right in all the languages that have dynamic polymorphism.  It just
isn't as efficient as it could be.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman
Technical Details
Message-ID: <567@coatimundi.cs.arizona.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!news.cs.indiana.edu!arizona.edu!arizona!gudeman

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!news.cs.indiana.edu!arizona.edu!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Runtime Polymorphism -- To Have and Have Not
Message-ID: <567@coatimundi.cs.arizona.edu>
Date: 2 Mar 91 23:37:36 GMT
Sender: news@cs.arizona.edu
Lines: 75