There are three ways languages deal with types.
- StaticTyping. This is where every variable, function parameter, and function return value has a type which is advertised in the language. This is typically used in compiled languages. The compiler can diagnose incompatible type errors. This is used in CeeLanguage and CeePlusPlus.
- DynamicTyping. This is where values have types and know their own types, but variables, function parameters, and function return values don't have types. In other words, in order to find out whether a function returns an integer or a string, you have to consult the code for that function, or the documentation, or you have to experiment with it -- the language itself doesn't tell you. This is typically used in interpreted languages, like SchemeLanguage and SmalltalkLanguage.
- No Typing. This is the typing that is used in AssemblyLanguage and ForthLanguage. A variable does not have a type, and a value does not know its own type. If you pass a Boolean to a function that expects a string, the function will interpret the bits of the Boolean as if they were bits that described a string, with possibly disastrous results. However, languages with no typing are the easiest to implement! (Not necessarily.) Note that not all languages actually have different types: see LambdaCalculus.
While it's true that
AssemblyLanguage doesn't "have types" in the sense that, say, C does, it does in fact have types -- just not "floats" or "enum" or other artificial constructs. Bytes and words and bits are very real types in
AssemblyLanguage, and addresses (pointers) are a real thing. Further, flags (a kind of bit, grouped in a word) are a type. What
AssemblyLanguage does not have is rules about higher level type abstractions. These can be crafted in
AssemblyLanguage, and the result is called a "compiler" or an "interpreter."
ForthLanguage has types when it's convenient, and eschews them when it's not. Oddly, although ForthLanguage is "higher level" than AssemblyLanguage, its very abstraction can create an effective "typelessness" where data can be either "waves or particles" depending on the programmer's mood. When a ForthLanguage context requires it, a word can be written to enforce typing semantics, but more often the programmer is allowed to be as strict or as loose as he deems appropriate. Think "stick shift" and "rack-and-pinion" with a machine shop in the back seat to build "cruise control" when needed.
-- GarryHamilton
http://perl.plover.com/yak/typing/typing.html is a very good article about type systems. Most of the examples are in C, Pascal and ObjectiveCaml. It hardly mentions perl.
For another typing model, see TypingQuadrant.
The following URL explains all of this much better than I did.
http://www.cs.cornell.edu/courses/cs412/2002sp/lectures/lec12.ps
The entire debate about typing seems to be deeply flawed because people are misusing terms like static/dynamic/weak/strong and also because the comparisons are always made between essentially flawed type systems like Pascal/C versus Smalltalk. I'd like to see some comparison of the type systems in OCaml/Haskell versus Smalltalk/Python/Ruby.--AdewaleOshineye
Three Kinds Of Typing