Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!keith@curry.uchicago.edu From: keith@curry.uchicago.edu (Keith Waclena) Newsgroups: comp.lang.misc Subject: Re: An Interesting View of "Strong" Vs. "Weak" Typing Summary: long Keywords: long Message-ID: <7049@tank.uchicago.edu> Date: 6 Jan 90 22:20:14 GMT References: <16622@megaron.cs.arizona.edu> Sender: news@tank.uchicago.edu Reply-To: keith@curry.uchicago.edu (Keith Waclena) Followup-To: comp.lang.misc Organization: TIRA / UofC Lines: 96 In-reply-to: gudeman@cs.arizona.edu (David Gudeman) 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.