Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!mcnc!unc!rentsch From: rentsch@unc.UUCP Newsgroups: comp.lang.misc Subject: Re: OOPS Message-ID: <923@unc.unc.UUCP> Date: Sun, 15-Feb-87 04:33:29 EST Article-I.D.: unc.923 Posted: Sun Feb 15 04:33:29 1987 Date-Received: Tue, 17-Feb-87 05:51:20 EST References: <364@oracle.tc.fluke.COM> <814@unc.unc.UUCP> <1040@tekchips.TEK.COM> Reply-To: rentsch@unc.UUCP (Tim Rentsch) Distribution: comp.lang.misc Organization: CS Dept, U. of N. Carolina, Chapel Hill Lines: 143 Summary: Static type checking AND dynamic binding (aka dynamic method lookup) Before starting, let me say thank you to Will Clinger (for heeding my plea, in his civilized posting) and also say thank you to Doug Moen (for his followup on dynamic {scoping versus binding}). Doug's posting pretty much represents my point of view on the terminology and scoping issues (thanks for saving me some keystrokes, Doug!), so I confine myself to the remaining issues. In article <1040@tekchips.TEK.COM> willc@tekchips.UUCP (Will Clinger) writes: > In article <814@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes: > >Side comment: I detect a hint of confusion between static binding > >and static typing. At the risk of repeating myself I caution against > >such confusion -- static type checking is perfectly compatible with > >dynamic binding. This compatibility does not, however, mean that > >statically checked systems can be statically bound. And, I apologize > >if in fact no confusion indeed exists. [And, glad to see more people > >realizing the value of inheritance etc as an improvement over (ugh!) > >C.] (End of side comment.) > To the contrary, static type checking is incompatible with dynamic > binding. I cannot disagree with the sentence "This compatibility > does not, however, mean that statically checked systems can be > statically bound" since I have been unable to divine its meaning. > [... some paragraphs deleted ...] > I suspect that Mr Rentsch intended the term "dynamic binding" to refer > to the dynamic method lookup described in the Smalltalk blue book. > Because Smalltalk is dynamically typed, the compiler cannot in general > determine the type of the object that will receive a given message. > Hence the compiler cannot determine which method should be used to > handle the message, and this determination must be made by the receiving > object at run time. Thus the dynamic method lookup. Granted: by 'dynamic binding' I do indeed mean binding of method name (aka message) to method body at runtime. Granted: a determination cannot in general be made as to the class of a message receiver (equivalent to the halting problem). Even so: by adding "type" declarations to a Smalltalk program, it is possible for the compiler to check "types" at compile time, and guarantee that 'message not understood' errors will not occur at runtime. This is what I meant when I said "static type checking is perfectly compatible with dynamic binding". On the other hand: even in the situation described in the paragraph above, it is not possible to know which method body will be bound to a given message (indeed more than one method body may be bound, at different times, to any particular message send). Even though we know at compile time that 'message not understood' errors cannot occur -- in other words the code is statically checked -- we do not know (cannot know) which methods will be bound to which message sends. This is what I meant when I said "This compatibility does not, however, mean that statically checked systems can be statically bound". [The quoted sentence wasn't very clear, was it? Oh, well.] > Someone asked whether dynamically typed languages can be made to run as > fast as statically typed languages. Well, if everything else is equal, > then static types are going to run faster. It's easy to overstate the > performance advantage of statically typed languages, though. If, for > example, you're computing with null-terminated linked lists, then you're > already working with a union type (nil union ...) so adding a few more > types to the union (to get a union that encompasses all types, as in a > dynamically typed language) isn't likely to slow your union discriminations > very much. And if you use integer arithmetic instead of arithmetic modulo > 2^32, then telling the compiler that a variable contains an integer doesn't > tell the compiler whether a modulo 2^32 addition instruction can be used to > increment it. And static types don't help with array subscript bounds > checking. Hence static types don't help much with performance once you > get beyond low-level languages like C and Ada; you can see this quite > clearly if you try to compare the performance of a statically typed > language like ML with a comparable dynamically typed language like Scheme. > The performance differential attributable to static versus dynamic types > will be swamped by unrelated differences in the quality of the > implementations. The real advantage of statically typed languages is > that they detect a certain class of bugs at compile time instead of run > time. Main point: the term "dynamic typing" as used here apparently means *both* dynamic method lookup and non-statically type checked systems. Except for that slight ambiguity I agree with most of the points made (exceptions follow). My main point is still that code may be statically checked (with the help of type declarations) even though it is dynamically bound. I agree: "The performance differential attributable to static versus dynamic types will be swamped by unrelated differences in the quality of the implementations." Almost always true. I agree: "The real advantage of statically type[checke]d languages is that they detect a certain class of bugs at compile time instead of run time." Amen. However: all else equal, staticly bound procedure calls will run faster *in the small*. But, dynamically bound method lookup can run faster *in the large* -- because reduced code size makes for less swapping. Minor clarification: Smalltalk method lookup is independent of how many "types" are in the "union". For this reason Smalltalk style dynamic method lookup will be faster, after some point, than the union discrimination approach to dynamic {whatever} used by languages with static {whatever}. ({Whatever} is here used in the same sense of 'method lookup' of 'dynamic method lookup'.) > Finally, I would like to say that there is nothing in the concept of > object-oriented programming that is incompatible with static types. > I would like to say that, but I won't because the concept of object- > oriented programming is so ill-defined that there are sure to be > people out there for whom the very term "object-oriented programming" > implies dynamic types. Granted: the term "object oriented programming" is hard to define. Granted: different people mean different things by the term. Point of view: Object oriented programming is a methodological mindset, one precept of which is that when sending a message we as the sender don't know the type of the receiver, and that we don't WANT to know. Note that I did not say we *can't* know, only that we don't know. Those holding this point of view might argue that it is perfectly possible to practice object oriented programming in FORTRAN, by "pretending" not to know the type of the receiver of the message. On the other hand, those same people might believe that the full power of object oriented programming can be achieved only by fully dynamic method lookup. From this point of view, whether or not OOP implies dynamic method lookup, it is better with it than without it. I believe: in practicing object oriented programming (and have said what I think it is, elsewhere [specifically SIGPLAN Sept 1982]). I believe: in the benefits of dynamic method lookup (which I call 'dynamic binding', whether mistakenly or not). I believe: in the benefits of static type checking -- at least on some days! cheers, Tim