develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?

Thread Previous | Thread Next
March 30, 2005 10:17
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Message ID:
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Ɵ)

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About