Mark-Jason Dominus wrote:
>
> Maybe I should also mention that last week I had a dream in which I
> had a brilliant idea for adding strong compile-time type checking to
> Perl, but when I woke up I realized it wasn't going to work.
What do you see as the major obstructions?
eval "" isn't too bad, because you can just forget about type inference
until after all use's and BEGIN{}'s have finished and you're about to
start the final run. Then you can allow any remaining eval""'s to trash
the inference.
Symbolic references are ok for user programs, because you can punt on
inference unless they use strict 'refs'. import() is much worse; you'd
need to alter Perl to either do those before the inferencer runs or make
a built-in Exporter that the typechecker is buddies with.
$class->$method may be survivable if you can infer the possible values
of $method most of the time.
Closures are tough, but they exist in many languages that people have
written inference engines for. You have to play some tricks to avoid
infinite loops in the inferencer.
Subroutine arguments cause trouble. They're a list, and most type
systems only allow a single type in lists. But if we use a list type
like (T1, T2, T3...) meaning the first element, if it exists, is of type
T1, the second of type T2, and the third and all remaining of type T3,
then we might be able to stem the precision hemorrhaging somewhat.
References scare me.
$b = 17; # $b(0) : integer
$b++; # $b(1) : number
$b .= "fish"; # $b(2) : string
$c{1000} = $b; # %c(0) : hash{integer -> string}
$c{2000} = \%c; # %c(1) : hash{integer -> string | integer ->
ref(hash)} + %c is exposed
$c{$$}->{$b} = 42; # %c(2) : hash{nonref scalar -> scalar?}
Tying is ok as long as it can be reduced to FETCH etc. calls.
When I get some time, I'm planning on prototyping a perl5 type
inferencer that handles the easy stuff and correctly punts on the harder
stuff. I should have it done by Christmas.
Christmas 2023 sounds about right.
