HaloO, Sam Vilain wrote:
Ah, yes, a notable omission. I understood a Seq as a list with individual types for each element, which are applied positionally.
I can understand that the type-checker can produce this type for immutable sequences.
The superclass for things like Pair.
Hmm, have to think about that. Tuple subtyping usually has the reverse logic where a larger tuple is a subtype if the common parts are subtypes.
Here's a quick mock-up of what I mean: role Seq[ \$types ] { submethod COMPOSE { # a la BUILD for classes loop( my $i = 0; $i < $types.elems; $i++ ) { # assumption: "self" here is the class # we're composing to, and "has" is a class # method that works a little like Moose self.has( $i++ => (isa => $types.[$i]) );
I don't understand this line. First of all, why the increment? Then what does the double pair achieve when given to the .has method? I guess you want a numeric attribute slot.
} } my subset MySeqIndex of Int where { 0 <= $_ < $types.elems }; method post_circimfix:<[ ]>( $element: MySeqIndex ) { $?SELF.$element;
This is also unclear. Firstly there's no $?SELF compile time variable anymore. Secondly you are using the invocant as method? Shouldn't that be the sequence index for retrieving the numerical attribute slot?
} } Seq is certainly interesting for various reasons. One is that it is a parametric role that takes an arbitrary set of parameters. In fact, it's possible that the type arguments are something more complicated than a list (making for some very "interesting" Seq types); the above represents a capture, but the above code treats it was a simple list.
Can type parameters of roles be handled through normal variables as your code does? Regards, --