HaloO Luke,
you wrote:
No, I think I agree with you here. But what happens if you change you're second-to-last line to:
my $a = foo(); $a.meth() = 8;
Perl 6 is both a statically typed language and a dynamically typed language, and the problems that I am addressing are mostly about the dynamic part.
My state of affairs is that these two lines of code lack declarations that clearly announce what the user of foo and X wanted: 1) &foo returns an X 2) an X does .meth()
Where, how and if these are implemented, autoloaded or what not is another business. Client side type checking ensures that no usage outside the declared behaviour occurs. For larger declarations I which to put them into an interface module, package, header or however that is called and include it.
On the implementation side we get the complementary definitions: 1) here's an X that does .meth() 2) here's a &foo that returns an X
The dynamism of Perl6 should revolve around how to bring these two sides of an interface together conveniently and efficiently. Just using 1% of a big package shouldn't let your 10-liner become a bloated pig!
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 :)
We assign the type "objects with an 'm' method that can take a single integer" to $a. This is a category of objects that spans many classes, and does not fit into a nice little tree. I think that before we take on such an idea, we should look for research about this kind of type inference.
Type calculations are not inherently difficult, especially when junctive values are at hand. The problem is that the inference can quickly diverge to the useless "something is done to an anything". Dwimmery works best when it bridges little gaps in an otherwise very rich semantic network. -- TSa (Thomas SandlaÃ)
