What is Expressiveness in a Computer Language

[Pascal Costanza]

Chris Smith wrote:
> 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.

The words "untyped" or "type-free" only make sense in a purely 
statically typed setting. In a dynamically typed setting, they are 
meaningless, in the sense that there are _of course_ types that the 
runtime system respects.

Types can be represented at runtime via type tags. You could insist on 
using the term "dynamically tagged languages", but this wouldn't change 
a lot. Exactly _because_ it doesn't make sense in a statically typed 
setting, the term "dynamically typed language" is good enough to 
communicate what we are talking about - i.e. not (static) typing.

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

No, there is more: There is safe and unsafe code (i.e., code that throws 
exceptions or that potentially just does random things). There are also 
runtime systems where you have the chance to fix the reason that caused 
the exception and continue to run your program. The latter play very 
well with dynamic types / type tags.

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

What type of person are you to tell other people what terminology to use? ;)

Ha! Here I used "type" in just another sense of the word. ;)

It is important to know the context in which you are discussing things. 
For example, "we" Common Lispers use the term "type" as defined in 
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_t.htm . You 
cannot possibly argue that "our" use of the word "type" is incorrect 
because in "our" context, when we talk about Common Lisp, the use of the 
word "type" better be consistent with that definition. (You can say that 
you don't like the definition, that it is unsound, or whatever, but that 
doesn't change anything here.)

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

What type system catches division by zero? That is, statically? Would 
you like to program in such a language?

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

Your problem doesn't exist. Just say "types" when you're amongst your 
own folks, and "static types" when you're amongst a broader audience, 
and everything's fine. Instead of focusing on terminology, just focus on 
the contents.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/