Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!bionet!ig!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: An Interesting View of "Strong" Vs. "Weak" Typing
Message-ID: <16678@megaron.cs.arizona.edu>
Date: 9 Jan 90 00:17:31 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 50

In article  <7049@tank.uchicago.edu> keith@curry.uchicago.edu (Keith Waclena) writes:

>Don't you think the distinction between ``dynamic typing'' and
>``static typing'' is a useful one?  The distinction is, who knows the
>types: the compiler or the run-time system?

Well, you make a good case for the distinction, but I have some
reservations.  First, the distinction between compiler and run-time
system is itself somewhat artifical.  Granted that the large majority
of modern programming languages make this distinction at some level,
the distinction is not fundamental to the idea of a programming
language.  Rather, it is an artifact of implementation (or so I
claim).

>I would say that Icon is weakly typed statically and strongly typed
>dynamically...
>
>I would say that C is weakly typed (or untyped) dynamically, and
>strongly-typed (but not too strongly) statically...

This last sentence bothers me.  It would be quite simple to implement
a C operator such as "(typeof) x" that returns some representation of
the type of the variable x.  Granted this operator _does_ have to
refer to the type information gathered at compile time (it probably
would be treated as a compile-time constant, like "(sizeof) x"), but
the type of x is still available at run-time.

I think a better method to make this sort of distinction is to use the
traditional definition of "typed" vs. "untyped" languages that I
described previously, and further to distinguish between kinds of type
systems.  Define "tagged type systems" as systems where the
representation of the data uniquely identifies both the type of the
data and its value.  Define "untagged type systems" as those systems
where representations are overloaded (i.e.: a single representation
stands for a different value in several different types), and the type
must be known before it is possible to determine exactly what value is
being represented.

The advantage of this terminology is that it does not refer to the
distinction between compiler and run-time system, except where the
distinction is an inherent part of what you are talking about.  That
is, you _have_ to distinguish between compiler and run-time system in
order to talk about whether types are known at compile time, but it is
not necessary to make this distinction when you are talking about the
way data is represented.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman