If declaring something using is is like current tie in that it specifies the backing implementation of something (as opposed to the logical domain), how does is dim(2) fit into things? Rather than the name of the tie-ing class, it's giving parameters or pragmas to the built-in implementation.
Then it occured to me: it works if the built-in class isn't called Array but rather called dim! That is, it ties it to the implementation called dim which takes a list of numbers as parameters.
So, is that elegant or kinky? I think it's trying to be a more general mechanism, just like how use is today more general but can be fundimentally seen as an inclusion mechanism.
The only thing is explaining something like that. use is taught to be for pragmas (arrange your file this way to implement one) or modules (arrange your file that way to implement one) and a naming convention to help the use-er know which to expect.
So, if is dim(2) is "different" than is Foo even though it uses the same underlying implementation with different combinations of other features (e.g. it derives from a built-in class and acts as an alias for it with simplified parameters), I think that needs to be clear up front. In this example, I feel more like it's changing a property of the regular type rather than specifying a different type. Does one (in the current state of the specification) use is to specify properties, as well as using the same keyword to totally change the underlying type? Perhaps that's the key, and also explains why it's using parens instead of square brackets.
In reply to Perl 6 'is dim' point by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |