Python from Wise Guy's Viewpoint

[Ed Avis]

Don Geddis <don at geddis.org> writes:

>Let's take as our ideal what a dynamic type system (say, a program in
>Lisp) would report upon executing the program.  The question is, can
>your type inference system make exactly the same conclusions at
>compile time, and predict all (and only!) the type errors that the
>dynamic type system would report at run time?
>
>The answer is no.

Indeed not.  But if you were using a statically typed language you'd
write the program in a slightly different style, one that does let
type errors be found at compile time.  For example instead of a
function that takes 'either an integer, or a string' with that checked
at run time, you'd have to be more explicit:

    data T = TI Integer | TS String

    f :: T -> Bool
    f (TI i) = ...
    f (TS s) = ...

The question is whether having to change your program in this way is
so horribly cramping that it negates the advantages from having errors
found earlier.  In my experience I haven't found that to be the case.

- Hmm, I wonder if I might make an analogy between type checking and
syntax checking.  In the language Tcl almost everything, including
code, is a string, and the 'if' statement is just something that takes
three strings and evaluates the first, followed by either the second
or third.  The syntax of these strings is not checked at compile time.
You can write code like

    if $cond { puts "hello" ( } else { puts "goodbye" }

and the syntax error in the 'hello' branch won't be found unless you
run a test case setting $cond true.

The question is, can a static syntax checking system make exactly the
same conclusions at compile time, and predict all and only the syntax
errors that Tcl would report at run time?

The answer is no.

Should we then conclude that compile-time syntax checking is not worth
having?

-- 
Ed Avis <ed at membled.com>