🚀 go-pugleaf

In article <602@optima.cs.arizona.edu> gudeman@cs.arizona.edu
(David Gudeman) writes:

[Disclaimer:  I usually find DG's contributions to be thoughtful and
accurate.  Exceptionally, I think this one was ill-conceived, and
dangerously close to a polemic.  This may have coloured my reaction
to it. -- ANW]

>				   Mathematical notation is generally
>closer to dynamically typed languages than to statically typed
>languages.

	& it was invented and had evolved long before the whole modern
problem of trying to describe problems and algorithms in a precise way
for computer consumption.  Such examples as we have of attempts at
precision in maths [eg, by Russell] are not very convincing.  We write
sloppy maths because "we all know what we mean" -- I don't think that's
a very good model for computer languages.

>						   Static typing
>originated, as near as I can determine, with low-level languages like
>Fortran an Algol that were little more than glorified assemblers.

	[I assume that Algol 60, rather than older or modern versions,
is meant.]  This statement is just historically ignorant.  Algol 60
was *specifically* designed to describe algorithms, independently of
the computer.  Static typing was certainly not put in to make code
generation easier;  indeed, it was widely thought that Algol 60 would
never be used in real compilers.  Fortran did not, for the most part,
have declarations at all;  and many people argued bitterly, using just
the same "busy work" arguments, against having them in Algol.  The view
that you should say what variables you want to use, and what you want
to use them for, prevailed (for good reason, in my opinion).

>		  For example if the length of an array is not included
>in the definition of the type, you can do arbitrary things to memory
>by setting out-of-bounds values in the array.  Semantically we say
>that the behavior of the program becomes undefined due to a type
>error.

	Well this is a matter of semantics [:-)].  The C fragment
"int a[10]; a[23] = 17;" might, in many implementations, do something
arbitrary to memory, but in my opinion it contains an error.  Making
the behaviour undefined is [perhaps wrong-headedly] a convenience
for the compiler writer.  Would C become more strongly typed if the
behaviour became defined in some way?

>With static typing you need a great deal of information at compile
>time to be able to guarantee strong typing.  This has two
>consequences: (1) you have to limit the forms of expressions to some
>set for which you know a type-checking decision procedure, and (2) you
>have to acquire type information somewhere.

	Ie, (1) you have to know what your expression is intended to do,
and (2) you have to use variables in a disciplined way.  I don't find
these "consequences" either irksome or undesirable.  When I write programs
in dynamically typed languages, I try hard to follow the same precepts.

>	      The computer is supposed to to busy work like checking
>type consistency, the programmer should no more be burdened with this
>than he should have to calculate constants.

	Type *consistency* is indeed the compiler's job, but I don't
find it unreasonable that I should document my identifiers.

>					      How would you like it if
>you could not rely on constant folding, so you had to calculate the
>values of all your constants?

	[Irrelevant aside:  you *can not* rely on constant folding.
The fragment "i := 2; j := 3;  if i/j != 2/3 then ..." will indeed
"fail" on many [arguably broken] systems, which may matter to the
Numerical Analyst.]

	There is a place for dynamic typing (I enjoy writing shell
scripts!), and a case for rapid prototyping, but there is also a
case for traditional declarations;  there is no need for either
"camp" to knock the other.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk