Python from Wise Guy's Viewpoint

Ed Avis ed at membled.com
Sat Nov 1 05:53:23 EST 2003


Pascal Costanza <costanza at web.de> writes:

>>>A type "error" detected at compile-time doesn't imply that the
>>>program will fail.
>> 
>>Actually it does, in a statically typed language.
>
>No, it doesn't.

Well, it's rather a meaningless question since all statically-typed
languages define their semantics only for well-typed expressions, and
so something like

   f :: Int -> Int
   x :: String = "hello"
   f "hello"

has no semantics, and so cannot be said to 'fail' or 'not fail'.  But
it seems pretty clear that if you did bypass the type checking and
compile such code, it would go wrong as soon as it was run.

>>If you write a function which expects a Boolean and you pass it a
>>string instead, it's going to fail one way or another.
>
>Yes, that's one example. This doesn't mean that this implication
>always holds. What part of "doesn't imply" is the one you don't
>understand?

I just gave one example - 'Boolean' and 'string' in the above are just
examples of one possible type mismatch.   But the same holds for any
other type mismatch.  You cannot call a function defined for type X
and pass a value of type Y, where Y is not an instance of X.

>I don't care for unreachable code in this specific context. A part of
>the program that passes a value of type "don't know" to a variable of
>type "don't know" might be unacceptable to a static type sytem,

Actually, an expressive static type system will allow this:

   f :: a -> a

f takes a parameter 'don't know' and returns a result of the same
type.  Or you can have the even more general a -> b, any type to any
type.  Such a function isn't especially useful however, since if you
know nothing at all about what the type supports (eg, not even
equality might be defined) then you can't promise much about the
return value.

>but might still not throw any exceptions at all at runtime.

>>(I do mean a type error and not a type 'error' - obviously if you
>>have some mechanism to catch exceptions caused by passing the wrong
>>type, you wouldn't want this to be checked at compile time.)
>
>Exactly.

Some statically-typed languages do support this, for example Haskell's
Dynamic library, but you have to ask for it explicitly.  For me, the
common case of a type error is when I've simply made a mistake, and I
would like as much help as possible from the computer to catch the
mistake as early as possible.  But one might want to suppress the
checking occasionally.

(However, with a more expressive type system you don't so often feel
the need to suppress it altogether.)

-- 
Ed Avis <ed at membled.com>




More information about the Python-list mailing list