Torben Ægidius Mogensen <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
