What is a type error?

[David Hopwood]

Chris Smith wrote:
> I <cdsmith at twu.net> 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 <david.nospam.hopwood at blueyonder.co.uk>