> Agreed. It should do compile-time verification, not runtime.
>
> That said, I still think there *might* be something to be said for
> compile-time 'hints' for explicitly _untyped_ values.
Perhaps there should be a distinction between "untyped" and "Object".
Something that is explicitly an Object must be dynamically cast to
conform to a narrower type (however dynamic casting actually works).
If a variable is untyped, i.e. not explicitly anything at all, it
could be subject to run-time automatic coercion (of course resulting
in an exception if they are incompatible). That would allow us
lazy folks to still get what we want with weak typing.
> Take the example:
>
> sub foo(str $s) {...}
>
> my str $a = 'blah'; # type 'str'
> my $b = 'blah'; # untyped, but set to a constant 'str'
> my $c = $a; # untyped, but set to a known typed 'str'
> my $d = $a + $b; # untyped, but known to be of type 'str'
>
> foo($a); # OK
> foo($b); # COMPILE ERROR
> foo($c); # COMPILE ERROR
> foo($d); # COMPILE ERROR
Requiring this kind of behavior (from a "standard writer" point of
view) wouldn't be such a good idea, though. You could say it's up to
the compiler to do whatever sort of data flow analysis it wants, and
may catch these things at compile time if it can. Consider this:
sub baz(Int $x) {...}
my $read = 0;
my $foo = 'Glippy glop gloopy';
for 1..10 {
$foo = <> if $read;
}
baz $foo; # ERROR: type incompatibility.
A smart compiler could catch that one, but a dumb one should be
allowed not to and defer it until runtime. But---it's probably the
case that there will still only be one Perl, so it's not really an
issue. Except for the doc folks.
Naturally, in a threaded environment, declaring something as C<is
shared> would be much like C<volatile> in C.
Luke
