Path: utzoo!news-server.csri.toronto.edu!rutgers!cmcl2!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Dynamic typing (part 3)
Message-ID: <602@optima.cs.arizona.edu>
Date: 11 Mar 91 22:55:24 GMT
Sender: news@cs.arizona.edu
Lines: 88

I have become convinced that many people still don't know what I mean
by "dynamic typing".  This is an indictment of computer science
educations in general, that such an important and pervasive paradigm
has been so neglected.  Dynamic typing is not a new or strange way to
program -- Lisp and SNOBOL are both nearly as old as Fortran, and they
are dynamically typed languages.  Mathematical notation is generally
closer to dynamically typed languages than to statically typed
languages.

In fact, I'd go so far as to claim that it is static type checking
that is the peculiar notion, not dynamic typing.  Static typing
originated, as near as I can determine, with low-level languages like
Fortran an Algol that were little more than glorified assemblers.
They had to give type declarations so that they could generate code
that an assembly language programmer expected to be generated for
expressions.  Much later, static typing took on religious significance
as an element of the great god Structured Programming, and became a
living force.  Now people have actually come to believe, against all
evidence, that static typing is important for program reliability.

Part of this belief is rooted in the confusion between weak typing and
dynamic typing.  The two are completely unrelated.  In fact, I'd claim
that most dynamicly typed languages are strongly typed in some sense.
What is the essential difference between strong and weak typing?  I
claim that it is that weakly typed languages can do bizarre things due
to type errors.  For example if the length of an array is not included
in the definition of the type, you can do arbitrary things to memory
by setting out-of-bounds values in the array.  Semantically we say
that the behavior of the program becomes undefined due to a type
error.

If we ignore the idea of when type checking is done, we can define
strong typing as follows:

strong typing		a language feature that guarantees that the
			behavior of a program never becomes undefined
			as a result of a type error.

All dynamically typed language I know have this feature.  In fact for
most of these languages there are no programs that have undefined
behavior,  I don't know whether any statically typed language can
make that claim.

With static typing you need a great deal of information at compile
time to be able to guarantee strong typing.  This has two
consequences: (1) you have to limit the forms of expressions to some
set for which you know a type-checking decision procedure, and (2) you
have to acquire type information somewhere.

The first consequence is unacceptable in my view -- I don't like it
when the set of things I can express are arbitrarily limited.  The
second consequence is also unacceptable if it means that the programer
is burdened with the job of providing this information (and that is
the case for the huge majority of statically, strongly typed
languages).  The computer is supposed to to busy work like checking
type consistency, the programmer should no more be burdened with this
than he should have to calculate constants.  How would you like it if
you could not rely on constant folding, so you had to calculate the
values of all your constants?  Yet this is the same sort of busy work
as writing type declarations.

I think that static typing took on religious significance as a result
of the problems with weak typing -- people didn't understand that the
two issues are orthogonal, and that there was an alternative to static
typing.  They that weak typing is a problem because it can lead to
undefined behavior -- which means it can be very hard to debug.  This
is a reasonable position to take, however the solution they came up
with was not reasonable.  The solution was to require more and more
restrictions to the set of legal expressions, and more and more
declarations from the programmer.

This was so burdensome that enormour amounts of further research went
into finding ways to undo the unpleasant effects of these decisions.
Thus we have 'typecase', polymorphic functions, polymorphic modules,
virtual functions, etc., ad nauseum.  Each feature adds semantic
burden to the language, making it harder to learn and harder to
implement.  And you still don't get the full expressiveness of dynamic
typing, which was the obvious solution to begin with.

The only real problem with dynamic typing is that it is (slightly)
less efficient that static typing.  However, there are two obvious
solutions to this problem, one of which I presented in part 2.  The
other is to start with a dynamically typed language and add optional
type declarations.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman