Front page | perl.perl6.language |
Postings from September 2006
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes: > Any thoughts? I'm still thinking about the practical implications of this... but what immediately occurs to me: The point of multiple, as opposed to single, dispatch (well, one of the points, and the only point that matters when we're talking about multis of a single invocant) is that arguments are not bound to a single type. So at first gloss, having a single prototype in the core for all same-named multis as in your proposal seems to defeat that use, because it does constrain arguments to a single type. I would hate for Perl 6 to start using C<Any> or C<Whatever> in the sort of ways that many languages abuse "Object" to get around the restrictions of their type systems. I think that, as a rule, any prototype encompassing all variants of a multi should not only specify types big enough to include all possible arguments, but also specify types small enough to exclude impossible arguments. In other words, to use your proposal, "our proto moose (Moose $x:)" should assert not just that all calls to the multi moose will have an invocant that does Moose, but also that all objects of type Moose will work with a call to the multi moose. That may have been implicit in your proposal, but I wanted to make it explicit. In practice, the ability to use junctive types, subsets, and roles like any other type makes the concept of "single type" a much less restrictive one in Perl 6 than in most languages. For example, if you wanted C<max> to work on both arrays and hashes, you could have our proto max (Array|Hash $container) Or you could define an C<Indexed> role that both Array and Hash do and have: our proto max (Indexed $container) So maybe this is a reasonable constraint. But it seems odd to me that Perl might then not allow me to write a C<max> that takes, say, Bags or Herds or whatever. And as I said before, I think a prototype of our proto max (Whatever $container) is incorrect too. What I really want is for max to be callable on anything that can do max, and not on anything that can't. Following that observation to its logical conclusion, at some point we get to the core containing prototypes like: our proto max(Maxable $container) our proto sort(Sortable $container) our proto keys(Keyable $container) which (I think) results in no better support for contracts, but merely requires gratuitious typing (in both senses of the word): where before we could just write our routine "multi max...", now we need to write both "multi max..." and remember to add "does Maxable" so Perl will let us compile it. My apologies if I'm attacking a strawman here; perhaps there's a saner way to allow the flexibility for users to define novel implementations of global multis while still having the prototypes well-typed. All that said, the globalness of multis does concern me because of the possibility of name collision, especially in big systems involving multis from many sources. Your proposal would at least make an attempt to define a multi not type-conformant with a core prototype throw a compile-time error, rather than mysterious behavior at runtime when an unexpected multi gets dispatched. TreyThread Previous | Thread Next