Pascal Costanza wrote: > Consider a simple expression like 'a + b': In a dynamically typed > language, all I need to have in mind is that the program will attempt to > add two numbers. In a statically typed language, I additionally need to > know that there must a guarantee that a and b will always hold numbers.
"Marshall" <[EMAIL PROTECTED]> replied: > I would not expect that the dynamic programmer will be > thinking that this code will have two numbers most of the > time but sometimes not, and fail. I would expect that in both > static and dynamic, the thought is that that code is adding > two numbers, with the difference being the static context > gives one a proof that this is so. I don't think the the problem is down at the atom level. It's really at the structure (tuple) level. If we view 'a + b' as applying the function + to some non-atomic objects a and b. The question is how well do we specify what a and b are. From my limited exposure to programs that use dynamic typing, I would surmise that developers who use dynamic typing have very broad and open definitions of the "types" of a and b, and they don't want the type system complaining that they have nailed the definitions down quite yet. And, if you read some of the arguments in this topic, one assumes that they want to even be able to correct the "types" of a and b at run-time, when they find out that they have made a mistake without taking the system down. So, for a concrete example, let b be a "file" type (either text file or directory) and we get a whole system up and running with those two types. But, we discover a need for "symbolic links". So, we want to change the file type to have 3 sub-types. In a dynamic type system, because the file "type" is loose (it's operationally defined by what function one applies to b), this isn't an issue. As each function is recoded to deal with the 3rd sub-type, the program becomes more functional. If we need to demo the program before we have worked out how symbolic links work for some operation, it is not a problem. Run the application, but don't exercise that combination of type and operation. In many ways, this can also be done in languages with type inference. I don't understand the process by which one does it, so I can't explain it. Perhaps someone else will--please.... Back to the example, the file type is not an atomic type, but generally some structure/tuple/list/record/class with members or fields. A function which renames files by looking at only the name field may work perfectly adequately with the new symbolic link subtype without change because the new subtype has the same name field and uses it the same way. A spell-check function which works on text files using the "contents" field might need to be recoded for symbolic links if the contents field for that subtype is "different" (e.g. the name of the target). The naive spell check function might appear to work, but really do the wrong thing, (i.e. checking if the target file name is made of legal words). Thus, the type problems are not at the atomic level (where contents is a string), but at the structure level, where one needs to know which fields have which meanings for which subtypes. -Chris -- http://mail.python.org/mailman/listinfo/python-list