Thomas Sandlaà writes:
> And of course the builtin functionality and the packages available
> from CPAN save the typical small scale programmer from extensive
> declarations. But to use a complex module you have to read
> documentation to get the idea to call .meth() in the first place.
> And then I like to get the hint from the compiler that there is
> no .mth() and happily correct the spelling error. Spotting these
> types of errors is were computers are much better than humans :)
And it sure would be able to spot that kind of error, supposing the sub
declaration is in scope. But suppose it weren't. Maybe that's a bit
hard to fathom if you haven't written an autoloader. Suppose, then,
that you have this code:
class CodeProxy {
has Code $.code is rw;
sub call ($a) {
$.code($a);
}
}
This is valid Perl 6, and anyone who says otherwise (because of type
signatures) is changing the Perl philosophy too much to be taken
seriously. Now, tell me at compile time whether the call inside `call`
is valid.
Of course, the alleged type inferencer can do some magic and make sure
that it is. It says that the $.code member variable is not just of type
`Code`, but of type `Code is sig($x) forall $x` (are siglets still
around?). Then this code would not fail to compile, but any code that
tried to assign an incompatible routine to the .code member would fail
to compile.
At runtime, you load in a new subclass of `CodeProxy`, `DoubleCodeProxy`
(this programmer apparently doesn't know that we support variadic
signatures :-)
class DoubleCodeProxy is CodeProxy {
method call ($a, +$b) {
.code().($a, $b);
}
}
Again, undisputably valid Perl 6. Every method takes an implicit `*%`,
so it's not an interface violation to add a new named parameter. And
now it's okay to assign a code object to $.code which manditorily takes
two parameters, if that object happens to be a `DoubleCodeProxy`. But
we can't tell whether it's a `DoubleCodeProxy` by type inference,
because we didn't even know what a `DoubleCodeProxy` was at compile
time.
C++ gets around this problem by disallowing a declaration like `has Code
$.code` -- All declarations must be fully specified. Perl is not going
to do that.
Unless I've mis-argued somewhere (I've been straining to get this
message done before my next class starts, so my thinking may be sloppy),
this example case requires the check to be put off until runtime. In
that case, you certainly can't use inferred type information to make any
semantic choices, and the best we can do is to use it as a compile-time
error checker (in the cases where it's capable of doing so) and as an
optimizer.
Luke
