Chris Smith wrote: > Marshall <[EMAIL PROTECTED]> wrote: > > While I am quite sympathetic to this point, I have to say that > > this horse left the barn quite some time ago. > > I don't think so. Perhaps it's futile to go scouring the world for uses > of the phrase "dynamic type" and eliminating them. It's not useless to > point out when the term is used in a particularly confusing way, though, > as when it's implied that there is some class of "type errors" that is > strictly a subset of the class of "errors". Terminology is often > confused for historical reasons, but incorrect statements eventually get > corrected.
Ok, so you (Chris Smith) object to the term "dynamic type". From a historical perspective it makes sense, perticular in the sense of tags. A dynamic type system involves associating tags with values and expresses variant operations in terms of those tags, with certain disallowed combinations checked (dynamicly) at run-time. A static type system eliminates some set of tags on values by syntactic analysis of annotations (types) written with or as part of the program and detects some of the disallowed compuatations (staticly) at compile time. Type errors are the errors caught by ones personal sense of which annotations are expressible, computable, and useful. Thus, each person has a distinct sense of which errors can (and/or should) be staticly caught. A personal example, I read news using Emacs, which as most readers in these newsgroups will know is a dialect of lisp that includes primitives to edit files. Most of emacs is quite robust, perhaps due to it being lisp. However, some commands (reading news being one of them) are exceptionally fragile and fail in the most undebuggable ways, often just complaining about "nil being an invalid argument" (or "stack overflow in regular expression matcher".) This is particularly true, when I am composing lisp code. If I write some lisp code and make a typographical error, the code may appear to run on some sample case and fail due to a path not explored in my sample case when applied to real data. I consider such an error to be a "type error" because I believe if I used a languages that required more type annotations, the compiler would have caught my typographical error (and no I'm not making a pun on type and typographical). Because I do a lot of this--it is easy enough for me to conjure up a small lisp macro to make some edit that it is a primary tool in my toolkit, I wish I could make my doing so more robust. It would not bother me to have to type more to do so. I simply make too many stupid errors to use emacs lisp as effectively as I would like. Now, this has nothing to do with real lisp programming, and so I do not wish to offend those who do that. However, I personally would like a staticly typed way of writing macros (and more importantly of annotating some of the existing emacs code) to remove some of the fragilities that I experience. I'm not taking avantage of the exploratory nature of lisp, except in the sense that the exploratory nature has created lots of packages which mostly work most of the time. Now, I will return this group to its much more erudite discussion of the issue. Thank you, -Chris ***************************************************************************** Chris Clark Internet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours) ------------------------------------------------------------------------------ -- http://mail.python.org/mailman/listinfo/python-list
