🚀 go-pugleaf

In article  <1991Mar14.151707.11686@maths.nott.ac.uk> Dr A. N. Walker writes:
]In article <602@optima.cs.arizona.edu> gudeman@cs.arizona.edu
](David Gudeman) writes:
]
]We write
]sloppy maths because "we all know what we mean" -- I don't think that's
]a very good model for computer languages.

I object to the term "sloppy".  We often don't give unnecessary and
redundant information because it isn't needed.  I think it's an
excellent 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.

No, I was refering to the earliest Algol tradition.

]  Fortran did not, for the most part,
]have declarations at all;

I said "static typing", not "type declarations".  Early FORTRAN had
static typing but some of the declarations were implicit.

]	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.

You are just arguing for array bounds checking -- arguably a form of
dynamic typing.

]  Making
]the behaviour undefined is [perhaps wrong-headedly] a convenience
]for the compiler writer.

Not just a convenience.  It makes it _possible_ to generate faster
code, not just easier.

]  Would C become more strongly typed if the
]behaviour became defined in some way?

Yes.

]>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.

Your (1) is meaningless.  Of course you have to know what an
expression is intended to do in any language.  This has nothing to do
with when type checking is done.  Your (2) is a subjective judgement
that can mean anything.  Static typing certainly does not enforce any
sort of discipline in the way you use variables unless by "discipline"
you mean "restricted to a single language type".  Then (2) becomes a
tautology: "static type enforcement forces you to use static types."
There is no inherent advantage (other than efficiency) to following
the "discipline" of restricting all your variables to a single
language type.

]  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.

I don't find your "consequences" undesireable either (using my own
definition of "disciplined").  I find the unrelated two consequence I
listed to be extremely undesirable.

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

I find it unreasonable that I should be forced by some language
designer who has no idea what I'm trying to do, to document my
variables in a specific way which may be completely worthless in the
specific task at hand.  And not just identifiers.  In a strongly
typed, statically typed language you have to declare the recursively
complete type of every data location reachable in the program.

]	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.

In the first place, dynamic typing is useful for full-scale working
programs, not just prototypes.  In the second, I'm not knocking the
usefulness of _optional_ type declarations.  I'm trying to point out
that there better alternatives to enforced static typing, and that
dynamic typing is not "dangerous".  There is absolutely no evidence
that dynamic typing is in any way unsafe, and considerable evidence to
the contrary.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman