peterr@utcsrgv.UUCP (Peter Rowley) (12/31/83)
Re declaring variables: You don't need any sort of formal type mechanism to
do this. Just a "declare" construct. e.g. declare a, b, i;
The catching-misspelled-variables advantage is just a side-benefit of having
to specify the type of a variable, albeit an important one.
Re Tim Maroney's definition of strong typing, whereby one can always determine
the type of an expression: This rather changes the problem to defining type
suitably. If one adopts the conventional definition of type as a set of
values and allowed operations, it doesn't help that much, as, given any
expression in any programming language, I can give you a set of values that
it can assume and a set of operators that the language allows you to apply
to that expression. In what are commonly called weakly-typed languages,
those sets will be larger than the sets for strongly-typed languages, but
they will exist. For example, the expression a + b in the "untyped"
language B, as implemented on large Honeywells, has a type consisting of
all those values that can be represented in 36 bits and all those operations
provided by the language.
To move to the other end of the spectrum, consider a + b in Pascal, where
a: 1..4 and b: 1..2. Then, the type of a + b is the set { 2, 3, 4, 5, 6 }
and all the operations allowed on integers. Certainly smaller than the sets
for B.
Using this framework, we have an easy definition of an untyped language--
all expressions have the same type.
But as for strong vs. weak typing, I defy anyone to come up with a fence
between the two that makes intuitive sense.
It is interesting, though, to consider a MOST-strongly-typed language, in
which all expressions have MINIMAL value and operation sets. What does
that mean? The value set would ONLY contain those values which the
variable would actually assume at run-time, yet this set would be computed
at compile-time. e.g.
var a: boolean; b:{10, 100}; /* new set constructor */
read(a); if a then b := 10 else b := 100; writeln(b)
I'm not sure how one would choose the minimal operation set; comments are
welcome, as are references to this sort of discussion in the literature.
I haven't seen discussion of most-strongly-typed languages before.
This discussion neglects the important role of type information as an aid
to mapping the elements of a program back into corresponding elements in
the problem domain. e.g. if I give a type of "salary" to a variable,
I know that the variable has a certain meaning in terms of the original
problem-- it represents someone's salary. By looking at the value
restrictions on the type, I could discover that, e.g., it must be at least
100.00 and can be at most 2000.00 and is kept to 2 decimal places of precision.
This tells me something about salaries in the bit of the world the program is
modelling. A lot more can be said, but this message is long already. The
point to note is that type information is not just an aid to catching
nonsense values and operations, such as discussed in the first part of this
message, but also program documentation. As such, it could be replaced by
comments (and this is done by B programmers) but integrating this aspect into
the language design seems to make programs look better and makes it a bit more
likely that the documentation will be there.
peter rowley, U. Toronto