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,
--
