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.

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 ) {

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?


Reply via email to