🚀 go-pugleaf

In article <16622@megaron.cs.arizona.edu>, gudeman@cs (David Gudeman) writes:
>I think there is some confusion here between "having types" and "being
>typed".  In particular, it is possible for a language to have types
>(as Smalltalk and CL do) and still to be untyped (as Smalltalk and CL
>are).  These languages are not "weakly typed", they are "untyped".
> [...]
>A language is said to "be typed" if the identifiers of the language
>(variable, function names, etc.)  are constrained to represent values
>of specific types.  The difference between strong and weak typing
>involves how much you can say about the types of values that the
>identifiers can take.
>

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?

I would say that Icon is weakly typed statically and strongly typed
dynamically, in that identifiers aren't type-constrained in any way,
and yet the Icon runtime system knows the types of all values at all
times.

I would say that C is weakly typed (or untyped) dynamically, and
strongly-typed (but not too strongly) statically, in that identifiers
in C are somewhat type-constrained, and yet the C runtime system knows
nothing at all about the types of values.

In other words, there are two sorts of things that can have varying
degrees of ``typing'' applied to them: L-values (i.e., locations or
identifiers) and R-values (i.e., values, or data).  Dynamic (runtime)
typing refers to the typing of the R-values, while static (compile
time) typing refers to the typing of the L-values.

I think this nicely ties together some of the other points people have
made in this thread: dynamic typing implies tagging your data, and
happens to be most often done in interpreter-based implementations,
while static typing implies some amount of compiler-checking, perhaps
as elaborate as a polymorphic type inference system.  If you want to
do no runtime checking, you can substitute static checking (at the
cost of some flexibility); if you want to do no compile-time checking,
you can substitute run-time checking at the cost of some runtime
speed.  And of course, you can mix the two approaches as much as you
like.

Here are some example languages and the sort of type checking they do
(we could of course argue about where a given language falls on the
continuum between ``strong'' and ``weak''); the ``Traditionally
compiled?'' column indicates whether implementations of that language
usually compile native code or interpret pseudocode (of course, any
language can go either way).

                                       Traditionally
Language        Dynamic         Static   Compiled?   Comments
--------        -------         ------   ---------   -------------------------
BCPL            Untyped         Untyped     yes      Only value is bit pattern
Forth           Untyped         Untyped     no       Ditto
C               Untyped         Moderate    yes
Icon            Very strong     Untyped     no
Scheme          Very strong     Untyped     no
Miranda         Weak?           Strong      no       Polymorphic type inference
Lazy ML		Weak?           Strong      yes      Polymorphic type inference


(I'm not *sure* that Miranda and Lazy ML do no runtime tagging...)

Clearly, most languages that provide a type-query function that
returns the type of any value at run-time must be said to be strongly
typed in *some* sense; I'd say that sense is ``dynamically'', because
I'd guess that language uses runtime tags.  For example, Icon has
``type''; Common Lisp has ``type-of'; Snobol4 has something similar.
(However, I think Algol 68 went to some pains to allow a typeof
function that worked without runtime tags, using instead some unusual
language structures (like the case-type statement that was used with
unions).  Does anyone know about this?)

BCPL and Forth have similar typing approaches, though one is usually
compiled and the other usually interpreted.  Scheme and Miranda are
similar languages, usually interpreted, which take (mutually) opposite
approaches to typing.

Note that in languages like BCPL and Forth, which are completely
untyped, it is the programmer who supplies the type information by
choosing the appropriate operators to apply to particular values.

(I don't suppose it makes much sense to apply the adverb
``traditionally'' to recent languages like Miranda and Lazy ML, but I
hope you get the picture.

							Keith

--
Keith WACLENA                             keith@curry.uchicago.edu
CILS / TIRA / U of Chicago                keith%curry@uchimvs1.bitnet
1100 E.57th.St Chi IL 60637 USA           ...!uunet!curry.uchicago.edu!keith

"Immer Sicherheitsfruchthalter benutzen!"               -- A. Boerner, Gmbh.