What is a type error?

[George Neuner]

On Mon, 26 Jun 2006 11:49:51 -0600, Chris Smith <cdsmith at twu.net>
wrote:

>Pascal Costanza <pc at p-cos.net> wrote:
>
>> This is maybe better understandable in user-level code. Consider the 
>> following class definition:
>> 
>> class Person {
>>    String name;
>>    int age;
>> 
>>    void buyPorn() {
>>     if (< this.age 18) throw new AgeRestrictionException();
>>     ...
>>    }
>> }
>> 
>> The message p.buyPorn() is a perfectly valid message send and will pass 
>> both static and dynamic type tests (given p is of type Person in the 
>> static case).
>
>It appears you've written the code above to assume that the type system 
>can't cerify that age >= 18... otherwise, the if statement would not 
>make sense.  It also looks like Java, in which the type system is indeed 
>not powerfule enough to do that check statically.  However, it sounds as 
>if you're claiming that it wouldn't be possible for the type system to 
>do this?  If so, that's not correct.  If such a thing were checked at 
>compile-time by a static type check, then failing to actually provide 
>that guarantee would be a type error, and the compiler would tell you 
>so.

Now this is getting ridiculous.  Regardless of implementation
language, Pascal's example is of a data dependent, runtime constraint.
Is the compiler to forbid a person object from aging?  If not, then
how does this person object suddenly become a different type when it
becomes 18?  Is this conversion to be automatic or manual?  

The programmer could forget to make a manual conversion, in which case
the program's behavior is wrong.  If your marvelous static type
checker does the conversion automatically, then obviously types are
not static and can be changed at runtime.  

Either way you've failed to prevent a runtime problem using a purely
static analysis.


George
--
for email reply remove "/" from address