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 discretion.
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*.) Stuart
