🚀 go-pugleaf

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.