Xref: utzoo comp.lang.misc:3884 comp.software-eng:2754 Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!att!cbnewsc!lgm From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka) Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: An Interesting View of "Strong" Vs. "Weak" Typing Keywords: typing, Ada, Lisp, definitions, evidence Message-ID: <12820@cbnewsc.ATT.COM> Date: 13 Jan 90 19:59:52 GMT References: <2197@ecs.soton.ac.uk> Reply-To: lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) Organization: AT&T Bell Laboratories Lines: 43 In article <2197@ecs.soton.ac.uk> rh@landin (R Harrison) writes: >The advantages of strong typing have been recognised for some time >- consider, for example, Gries and Gehani ("Some ideas on data type >in high level languages, CACM 20, 1977, pp.414-420), in which the case >for controlled polymorphic programming is discussed. Gries and Gehani bring up the alternative of run-time typed languages (the authors call them "typeless") in a single paragraph at the end of their article. Interestingly, they mention as examples APL and Snobol but omit Lisp, which I suspect was the most widely used of the three even in those days. (The Interlisp and MIT Lisp machine programming environments already existed in 1977, though they were perhaps not yet well known.) The authors reject such languages for three reasons. First, Gries and Gehani complain of interpretive implementations. This accusation no longer applies - not to Common Lisp, anyway. Second, the authors mention the unparsability of APL. This difficulty, for which Gries and Gehani give an example, does not apply to other run-time typed languages. Indeed, the accusation today is much more applicable in the opposite direction: Common Lisp is particularly easy to parse, whereas C++ is practically unparsable. (Send me mail for a particularly nasty example.) The authors' third reason for rejecting run-time typing is that "one cannot tell just by looking at a procedure just what it does; it will depend too heavily on the inputs to that procedure." This objection is equally applicable, of course, to the authors' own proposal of parameterized types. More ironic is the fact that many popular language abstractions, including object-oriented programming itself, are equally vulnerable to this same accusation. And of course, Gries and Gehani give no concrete evidence of the superiority of their preferences. Indeed, their primary criteria - listed as readability, understandability, provability of correctness, and run-time efficiency - apparently do not include productivity, extensibility, or evolvability. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.