Path: utzoo!attcan!uunet!mcvax!ukc!etive!lfcs!nick From: nick@lfcs.ed.ac.uk (Nick Rothwell) Newsgroups: comp.lang.misc Subject: Polymorphism (Re: What is B&D?) Message-ID: <1228@etive.ed.ac.uk> Date: 12 Jan 89 12:18:01 GMT References: <8540@megaron.arizona.edu> <2630@ficc.uu.net> <13293@cup.portal.com> <5795@medusa.cs.purdue.edu> <2670@ficc.uu.net> <5818@medusa.cs.purdue.edu> Sender: news@etive.ed.ac.uk Reply-To: nick@lfcs.ed.ac.uk (Nick Rothwell) Organization: Laboratory for the Foundations of Computer Science, Edinburgh U Lines: 29 In article <5818@medusa.cs.purdue.edu> rjh@cs.purdue.edu (Bob Hathaway) writes: >Generics and Milner's type inference system are >examples of statically checked (typed) polymorphism. This form can be >accomplished at compile time and offers strong type checking. Dynamic >typechecking, which I often refer to as arbitrary polymorphism, is a more >powerful form and usually cannot be accomplished at compile time. ^^^^^^^ Well, cannot at all, I'd say, by definition of compile-time and dynamic. Re: dynamic typechecking being "more powerful" than static typechecking. More powerful, perhaps, in that you have the option of allowing functions to determine, during execution, the form (type) of their arguments. But, a static typechecking system can *guarantee* that a program, if correctly statically typed, cannot ever give you a type error, no matter what execution paths are taken. A dynamically typed program doesn't give you this guarantee - how do you know that some bizarre pattern of inputs won't cause a type error? Look at a lisp system, with messages like "wrong type: fredp, nil" coming up in supposedly correct code, to see what I mean. >Bob Hathaway Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk !mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.