[EMAIL PROTECTED] wrote: > Rob Thorpe wrote: > > > > But it differs from latently typed languages like python, perl or lisp. > > In such a language there is no information about the type the variable > > stores. The programmer cannot write code to test it, and so can't > > write functions that issue errors if given arguments of the wrong type. > > The programmer must use his or her memory to substitute for that > > facility. As far as I can see this is a significant distinction and > > warrants a further category for latently typed languages. > > Take one of these languages. You have a variable that is supposed to > store functions from int to int. Can you test that a given function > meets this requirement?
The answer is no for python and perl AFAIK. Also no for lisp _aux naturelle_ (you can do it by modifying lisp though of-course, I believe you can make it entirely statically typed if you want). But the analogous criticism could be made of statically typed languages. Can I make a type in C that can only have values between 1 and 10? How about a variable that can only hold odd numbers, or, to make it more difficult, say fibonacci numbers? > You see, IMO the difference is marginal. From my point of view, the > fact that you can do such tests *in some very trivial cases* They are not very trivial for practical programming purposes though, they are important. > in the > languages you mention is an artefact, nothing fundamental. The cases can be far from trivial. In lisp a type specifier can mean something like "argument must be a 10x10 matrix with top corner element larger than 35" You can also, for example, easily make predicates that tell if a value is odd, or a fibonacci number. The system simply extends in different directions. -- http://mail.python.org/mailman/listinfo/python-list