Chris Smith wrote: > I <[EMAIL PROTECTED]> wrote: > >>Incidentally, I'm not saying that such a feature would be a good idea.
I don't think it would be a bad idea. Silently giving incorrect results on arithmetic overflow, as C-family languages do, is certainly a bad idea. A type system that supported range type arithmetic as you've described would have considerable advantages, especially in areas such as safety-critical software. It would be a possible improvement to Ada, which UUIC currently has a more restrictive range typing system that cannot infer different ranges for a variable at different points in the program. I find that regardless of programming language, relatively few of my integer variables are dimensionless -- most are associated with some specific unit. Currently, I find variable naming conventions helpful in documenting this, but the result is probably more verbose than it would be to drop this information from the names, and instead use more precise types that indicate the unit and the range. When prototyping, you could alias all of these to bignum types (with range [0..+infinity) or (-infinity..+infinity)) to avoid needing to deal with any type errors, and then constrain them where necessary later. >>It generally isn't provided in languages specifically because it gets to >>be a big pain to maintain all of the type specifications for this kind >>of stuff. It would take a little more work to write a program, but it would be no more difficult to read (easier if you're also trying to verify its correctness). Ease of reading programs is more important than writing. > There are other good reasons, too, as it turns out. I don't want to > overstate the "possible" until it starts to sound like "easy, even if > it's a pain". This kind of stuff is rarely done in mainstream > programming languages because it has serious negative consequences. > > For example, I wrote that example using variables of type int. If we > were to suppose that we were actually working with variables of type > Person, then things get a little more complicated. We would need a few > (infinite classes of) derived subtypes of Person that further constrain > the possible values for state. For example, we'd need types like: > > Person{age:{18..29}} > > But this starts to look bad, because we used to have this nice property > called encapsulation. I think you're assuming that 'age' would have to refer to a concrete field. If it refers to a type parameter, something like: class Person{age:Age} is Age getAge() end then I don't see how this breaks encapsulation. -- David Hopwood <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list