What is a type error? [correction]

[David Hopwood]

Darren New wrote:
> David Hopwood wrote:
> 
[...]
>> Apparently, Hermes (at least the version of it described in that paper)
>> essentially forgets that is_last has been initialized at the top of the
>> loop, and so when it does the merge, it is merging 'not necessarily
>> initialized' with 'initialized'.
> 
> No, it's not that it "forgets". It's that the "insert line into inputs"
> unitializes "line". Hence, "line" is only conditionally set at the
> bottom of the loop, so it's only conditionally set at the top of the loop.
> 
>> This sounds like a pretty easy thing to fix to me (and maybe it was fixed
>> later, since there are other papers on Hermes' typestate checking that I
>> haven't read yet).
> 
> You simply misunderstand the "insert line into inputs" semantics.

Yes, you're right, I did misunderstand this.

> Had that line actually been commented out in the Hermes code, the loop would
> have compiled without a problem.
> 
> That said, in my experience, finding this sort of typestate error
> invariably led me to writing clearer code.
> 
> boolean found_ending = false;
> while (!found_ending) {
>   string line = getString();
>   if (line.charAt(0) == 'q')
>     found_ending = true;
>   else
>     insert line into inputs;
> }
> 
> It seems that's much clearer to me than the contorted version presented
> as the example. If you want it to work like the Java code, where you can
> still access the "line" variable after the loop, the rearrangement is
> trivial and transparent as well.

I agree.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>