🚀 go-pugleaf

> From: nick@lfcs.ed.ac.uk (Nick Rothwell)
> there's a difference between a language "being typed" and a
> language providing a rigorous and structured framework in which to
> construct, reason about, and exercise abstractions and interfaces.  I
> can't do the latter in C even through it knows about integers, reals,
> records etc. since the type "system" isn't sufficiently powerful
> to handle interfaces and abstraction.

C (at least draft ANSI C) also "knows about" prototypes, structure types,
and pointers to unelaborated structure types.  These tools are enough
to "handle" interface and data abstraction well enough to get by, but
of course these tools are (at best) ad hoc.  So while I agree that C does
NOT have a very good type description notation, it has enough to get
by for many practical uses.

But more generally, I think that the issue of type "strength" is being
confused by a difference between language examples I don't see brought
out in the tables in any of the articles posted so far.  That is the
distinction between languages where names are bound to containers (such
as FORTRAN) and languages where names are bound to values (such as
LISP).  This is related to the issue of type tagged languages, but it
isn't quite the same issue.  In some languages, containers are typed, in
others values are typed.  In languages where containers are typed, it is
possible that containers be referred to by values, and hence either of
these kinds of languages can be tagged to one extent or another. 

So we have compiletime/runtime, static/dynamic, non-tagged/tagged,
named-container/named-value, typed-container/typed-value distinctions
to worry about, and strongly-typed/weakly-typed is not strictly tied
to any of these distinctions (but it does make it harder to characterize
strong/weak type distinctions).  (And we COULD bring in 
descriptive/procedural, modular/monolithic namespace, and so on and on.)
And to top it off, all of these distinctions are more or less fuzzy.


I try nowadays not to use the terms "strongly typed" or "weakly typed",
because so many people mean so many things by them.  If I had to state
what they meant to me, I'd say something like

    Strongly typed languages are those languages where the correspondence
    between typed values and the operations the programmer intends to allow
    on those typed values can be made known to the language system, and
    weakly typed languages are those languages where this correspondence
    must be managed by the programmer. 

Under this definition of "strong" and "weak" types, I'd say that C is a
somewhat strongly typed language which is often used as a somewhat
weakly typed language by people who take advantage of the traditional
lack of diagnostic messages produced by the traditional language
processors for the language. 

Or to put it another way, C is like a machine tool from which the
safety sheilds can be removed (that is, one isn't forced to run lint).
While this is intended to be done only for efficency's sake, and only
when the area is cleared (when producing object code for source code
known not to violate the rules of the language), many operators run
with sheilds removed.  It's really quite fortunate that C compilers
don't snatch off fingers or whole limbs like machine tools do.
They just produce bad code.


> From: keith@curry.uchicago.edu (Keith Waclena)
> [.. A typeof operator for the C language ..]
> can't be done as a compile-time operator (like
> sizeof) except for identifiers (see below), while the type-of-like
> operators of Icon and Common Lisp work on values.  Because C allows
> unions and pointers you would have to have runtime tags to do this.
> I think the real distinction is between associating type information
> with identifiers (l-values) and associating it with data (r-values).
> A language can do one, or the other, or both, and it can do either
> strongly or weakly.

Actually, a language can associate type information with identifiers,
containers, or values.  C associates types with containers and values,
but sometimes the value of certain expressions are undefined, which
can happen several ways.

So, the thing to note is that a typeof operator COULD be added to
C as a compile-time operation on both r-values and l-values.  There
is no ambiguity about what type any expression or identifier has...
unions and pointer casts only add ambiguity about whether the value
of some expressions are defined.

It is this property of C (and most algol-related languages' type
systems) that leads me to my contention that strength of typing isn't
related only to how much one knows about the type of various
expressions.  It seems to me that in essentially all algol-related
languages (those without admixtures of LISP or functionally pure
notation at least), this information is always statically known, and is
unambiguous.  Yet in C for example, one must keep track "by hand" of
what operations are allowed at what times, because of the ambiguities
introduced by pointer casts and unions (among other things). 
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org