HaloO, Jonathan Lang wrote: > OK. My main dog in this race is the idea of defining new roles > through the concepts of the intersection or difference between > existing roles
Note that you should not call these 'intersection type' because this term is used for the union of role interfaces. That is the typist intersects the extension sets of objects doing the roles that are combined. IOW, set operations for roles could also be defined the other way around. If that solves the perceptive dissonance of a typical Perl programmer that Larry mentioned, I don't know. > And yes, this "roles as sets" paradigm would presumably mean that you > could examine roles using '⊂', '⊃', '∈', and so on. Given the > semantic aspect of roles, I don't think that I'd go along with saying > that 'A ⊃ B' is equivalent to 'A.does(B)' - although I _would_ agree > that if 'A.does(B)' then 'A ⊃ B'. Rather, I'd think of 'A ⊃ B' as > being the means that one would use for duck-typing, if one really > wanted to (presuming that one can mess with how perl 6 does > type-checking). I guess up to now it is undefined how structural and how nominal the Perl 6 type system is. But I agree that when a role A says that it does B that the type system should check if A ⊃ B. I believe that it should be possible to fill a node in the type lattice with a named role precisely to catch dispatches to this intersection, union or another combination interface. Or you instanciate parametric roles for the same purpose. Note that union interfaces might need some merging of signatures as I tried to argue elsewhere. Also, we might allow the subrole to change signatures in accordance with the intended subtype relation. Regards, TSa. --
