Test cases and static typing

[Pascal Costanza]

Dirk Thierbach wrote:

> Pascal Costanza <costanza at web.de> wrote:
> 
> 
>>A flexible and useful IDE must treat static type checking as a separate 
>>tool. It needs to be able to do useful things with code that isn't 
>>correct yet. 
> 
> I don't agree with the "must", but type checking is a seperate phase
> in the compiler. It should be possible to make an IDE that treats
> it that way. But I doubt that particular point is high on the priority
> list of any potential programmer of an IDE. 

No, it's only high on the priority list of actual programmers of IDEs. 
For example, you could check what Eclipse has to offer for Java in that 
regard.

>>And that's all I wanted from the very beginning - static typing as an 
>>additional tool, not as one that I don't have any other choice than use 
>>by default.
> 
> And that's fine, but it is not an issue of static typing.
> 
>>>>>>The type system might test too many cases.
> 
>>No, it's not better to give an example in a different language. The 
>>whole point of my argument is that the code above cannot be statically 
>>type-checked. 
> 
> You can look now at two examples of code like this that can be
> statically type-checked.

I am not convinced, but let's play that game for a while: OK, we have 
three programs that have the same behavior, and they especially all 
behave well. Only two of them can be statically type checked.

This completes my proof that static type systems reduce expressive power.

> And I had the impression that you wanted to explain why a "type system
> might test too many cases". I still don't understand this argument. I
> don't see any "case" that the type system will test in the above
> program, let alone "too many".
> 
>>>I could probably rewrite the code with an approximation to cerror
>>>(with the restriction that non-local control structures don't 
>>>translate one to one), but even then I don't see why the type system
>>>would test too many cases for this example.
> 
>>I don't want an "approximation of cerror". I want cerror!
> 
> Then use Lisp and cerror. Nobody forces you to use anything else. The
> problem is again that you want to do it only in exactly the same way
> as you are used to doing it. You don't see how to do it in another
> language, and then you say "it cannot be done". And that's just wrong.

I don't say it cannot be done. Don't put words into my mouth.

In this case, you actually need to write additional code to simulate 
dynamic checks in a statically typed language that a dynamically typed 
language gives you for free. I am sorry, but I don't see any advantage 
in such an approach.

> So can we settle on "you like to do it your way, but it is possible
> to do everything you want in a statically typed language if
> you're a little bit more flexible"? (That means of course that if
> you refuse to be a bit more flexible, it cannot be done in exactly
> the same way -- after all, they are different languages.)

Well, in my book the computer should adapt to what I want, and not the 
other way around.

> As long as you say "this cannot be done" you'll get answers showing
> you that it can indeed be done, only in a way that is a little bit
> different. Then you say "yes, but that's not how I want it. You're
> trying to force to use me something I don't want!".

No, I haven't said it cannot be done. I have talked about expressive 
power, and that's something different.

> It gets a bit silly after some iterations.

Indeed.


Pascal