Rob Thorpe wrote: > Vesa Karvonen wrote: > >>In comp.lang.functional Anton van Straaten <[EMAIL PROTECTED]> wrote: >> >>>Let me add another complex subtlety, then: the above description misses >>>an important point, which is that *automated* type checking is not the >>>whole story. I.e. that compile time/runtime distinction is a kind of >>>red herring. >> >>I agree. I think that instead of "statically typed" we should say >>"typed" and instead of "(dynamically|latently) typed" we should say >>"untyped". [...] >>>It's certainly close enough to say that the *language* is untyped. >> >>Indeed. Either a language has a type system and is typed or has no >>type system and is untyped. I see very little room for confusion >>here. In my experience, the people who confuse these things are >>people from the dynamic/latent camp who wish to see types everywhere >>because they confuse typing with safety or having well-defined >>semantics. > > No. It's because the things that we call latent types we use for the > same purpose that programmers of static typed languages use static > types for. > > Statically typed programmers ensure that the value of some expression > is of some type by having the compiler check it. Programmers of > latently typed languages check, if they think it's important, by asking > what the type of the result is. > > The objection here is that advocates of statically typed language seem > to be claiming the "type" as their own word, and asking that others use > their definitions of typing, which are really specific to their > subjects of interest.
As far as I can tell, the people who advocate using "typed" and "untyped" in this way are people who just want to be able to discuss all languages in a unified terminological framework, and many of them are specifically not advocates of statically typed languages. -- David Hopwood <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list