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

Reply via email to