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

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Ã)

Reply via email to