The more I think about it, the more I'm convinced that perl6 (by
default) shouldn't refuse to run programs because of a (perceived or
real) type error.  It should, of course, emit a compile-type type
*warning*, which can be silenced or made fatal at the user's

There are a few reasons behind this:

1) If I'm not using type annotations in my code, I shouldn't be forced
to go out of my way to satisfy the typechecker before my program will
even run, just because I used external subs that have (incompatible)
type annotations.  Of course, my program will fail at run-time when
the predicted type error actually occurs, but in this case we're no
worse off than in any other dynamically-typed language--and at least I
had advance warning from the compiler.

2) Even if a program has a compile-time type error, it may be possible
to use part of the program's functionality without ever encountering a
run-time type error.  If a program has two modes, A and B, and the
type errors are all in the code for B, it makes no sense to prevent
the program from running in mode A.  If I'm trying to fix run-time
bugs in A, I shouldn't have to repair B before I can even start.

3) perl6 should be quite capable of running an ill-typed program,
right up until the point at which a run-time type error actually
occurs.  Perl 6 isn't one of those languages that needs code to be
well-typed in order for the compiler/runtime to figure out how to
actually execute it.  (Well-typedness helps for optimisation, of
course, but it isn't *required*.)


Reply via email to