What is Expressiveness in a Computer Language

[Chris Smith]

Torben Ægidius Mogensen <torbenm at app-3.diku.dk> wrote:
> That's not really the difference between static and dynamic typing.
> Static typing means that there exist a typing at compile-time that
> guarantess against run-time type violations.  Dynamic typing means
> that such violations are detected at run-time.  This is orthogonal to
> strong versus weak typing, which is about whether such violations are
> detected at all.  The archetypal weakly typed language is machine code
> -- you can happily load a floating point value from memory, add it to
> a string pointer and jump to the resulting value.  ML and Scheme are
> both strongly typed, but one is statically typed and the other
> dynamically typed.

Knowing that it'll cause a lot of strenuous objection, I'll nevertheless 
interject my plea not to abuse the word "type" with a phrase like 
"dynamically typed".  If anyone considers "untyped" to be perjorative, 
as some people apparently do, then I'll note that another common term is 
"type-free," which is marketing-approved but doesn't carry the 
misleading connotations of "dynamically typed."  We are quickly losing 
any rational meaning whatsoever to the word "type," and that's quite a 
shame.

By way of extending the point, let me mention that there is no such 
thing as a universal class of things that are called "run-time type 
violations".  At runtime, there is merely correct code and incorrect 
code.  To the extent that anything is called a "type" at runtime, this 
is a different usage of the word from the usage by which we may define 
languages as being statically typed (which means just "typed").  In 
typed OO languages, this runtime usage is often called the "class", for 
example, to distinguish it from type.

This cleaner terminology eliminates a lot of confusion.  For example, it 
clarifies that there is no binary division between strongly typed 
languages and weakly typed languages, since the division between a "type 
error" and any other kind of error is arbitrary, depending only on 
whether the type system in a particular language happens to catch that 
error.  For example, type systems have been defined to try to catch unit 
errors in scientific programming, or to catch out-of-bounds array 
indices... yet these are not commonly called "type errors" only because 
such systems are not in common use.

This also leads us to define something like "language safety" to 
encapsulate what we previously would have meant by the phrase "strongly 
dynamically typed language".  This also is a more general concept than 
we had before.  Language safety refers to a language having well-defined 
behavior for as many operations as feasible, so that it's less likely 
that someone will do something spectacularly bad.  Language safety may 
be achieved either by a type system or by runtime checks.  Again, it's 
not absolute... I'm aware of no language that is completely determinate, 
at least if it supports any kind of concurrency.

This isn't just a matter of preference in terminology.  The definitions 
above (which are, in my experience, used widely by most non-academic 
language design discussions) actually limit our understanding of 
language design by pretending that certain delicate trade-offs such as 
the extent of the type system, or which language behavior is allowed to 
be non-deterministic or undefined, are etched in stone.  This is simply 
not so.  If types DON'T mean a compile-time method for proving the 
absence of certain program behaviors, then they don't mean anything at 
all.  Pretending that there's a distinction at runtime between "type 
errors" and "other errors" serves only to confuse things and 
artificially limit which problems we are willing to concieve as being 
solvable by types.

> Anyway, type inference for statically typed langauges don't make them
> any more dynamically typed.

Indeed it does not.  Unless it weakens the ability of a compiler to 
prove the absence of certain program behaviors (which type inference 
does not), it doesn't move anything on the scale toward a type-free 
language.

That being said, though, it is considered a feature of some programming 
languages that the programmer is asked to repeat type information in a 
few places.  The compiler may not need the information, but for 
precisely the reason that the information is redundant, the compiler is 
then able to check the consistency of the programmer in applying the 
type.  I won't get into precisely how useful this is, but it is 
nevertheless present as an advantage to outweigh the wordiness.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation