Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!cae780!tektronix!tekcrl!tekchips!willc
From: willc@tekchips.UUCP
Newsgroups: comp.lang.misc
Subject: Re: OOPS
Message-ID: <1040@tekchips.TEK.COM>
Date: Tue, 10-Feb-87 20:35:28 EST
Article-I.D.: tekchips.1040
Posted: Tue Feb 10 20:35:28 1987
Date-Received: Thu, 12-Feb-87 07:24:53 EST
References: <364@oracle.tc.fluke.COM> <814@unc.unc.UUCP>
Reply-To: willc@tekchips.UUCP (Will Clinger)
Distribution: comp.lang.misc
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 101

In article <814@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes:
>Note to potential Follow-uppers:  if someone has something
>constructive to say, fine.  But please avoid the temptation to quote
>a line or two out of context and reply debate style.  You will be
>wasting our time and your breath.  I realize nits can be picked, but
>the points I present here are made over paragraphs, not sentences.
>Clear?

>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.

To understand why static type checking is incompatible with dynamic
binding, let us consider the example of a dynamically bound Lisp in
which the + operation applies only to objects of type number.  It
is impossible to perform static type checking on the procedure foo
defined by

    (define (foo n)
      (+ x n))

because the compiler has no idea what x is going to be bound to
dynamically.  The compiler can't tell what x is going to be bound
to by looking at all the places where x is bound, either:

    (define (bind-x-and-call-foo x n)
      (if (hairy-looking-predicate-that-always-returns-true n)
          (foo n)
          36))

    (define (bind-x-but-dont-call-foo x n)
      (if (not (hairy-looking-predicate-that-always-returns-true n))
          (foo n)
          37))

    (define (hairy-looking-predicate-that-always-returns-true n)
      ; n is an integer encoding a two-dimensional map
      ; returns true if there exists a four-coloring of the map
      ; algorithm: exhaustion of cases
      ...)

Similar examples can be constructed in other dynamically bound languages
such as APL.

The language that Mr Rentsch seems to be most fond of, Smalltalk-80, is
not a dynamically bound language.  I am by no means fluent in Smalltalk,
but it appears to me that Smalltalk-80 variables are either global or
local; local variables have lexical scope; local variables are not
permitted to shadow global variables, I've been told; and there are
a few oddball variables such as self and super that may not always obey
the rules. Smalltalk-80 is, however, dynamically typed.

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.

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.

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.

William Clinger
Tektronix Computer Research Lab