Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!mcnc!rti!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.lang.misc Subject: Re: An Interesting View of "Strong" Vs. "Weak" Typing Summary: "it's more complicated than that", and "C's types aren't all that flabby" Message-ID: <0335@sheol.UUCP> Date: 10 Jan 90 17:15:11 GMT References: <1493@castle.ed.ac.uk> <12610@cbnewsc.ATT.COM> <1516@castle.ed.ac.uk> <7106@tank.uchicago.edu> Lines: 95 > 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 !mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org