TSa wrote:
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.
It is? Where? I can't find it in any of the Synopses.
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.
I think that defining the union of role interfaces as an
"intersection" would only lead to confusion. Keep things clear:
"A(&)B" is the intersection of A and B, and includes in its interface
only those elements that are common to both A's and B's interfaces;
"A(|)B" is the union of A and B, and includes in its interface
everything in A's interface and everything in B's interface. "A-B" is
the difference of A and B, and includes in its interface everything in
A's interface that isn't in B's interface.
> 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.
It's not explicitly stated, as far as I can see; but it does seem to
be implied that type-checking makes use of .does(), and that .does()
is essentially nominal (for a sufficiently broad definition of
"name").
But I agree that when a role A says that it
does B that the type system should check if A ⊃ B.
I disagree. It's implicit that if A.does(B), then A ⊃ B; so checking
the latter as well as the former would be redundant. Meanwhile, the
converse is _not_ true: it is quite possible for A ⊃ B to be true
while A.does(B) is false. Using something closer to a nominal
approach allows the role's "name" to convey the semantics, something
that a strictly interface comparison would be unable to do.
Note that union interfaces might need some merging of signatures as
I tried to argue elsewhere.
The only merging of signatures that I'd want to see would be to drop
them entirely in the case of a collision of non-multi methods.
Also, we might allow the subrole to change
signatures in accordance with the intended subtype relation.
Note that perl 6 doesn't speak of subroles; and while it _does_ speak
of subtypes, it means something entirely different by the term than
what type theory means by it: in perl 6, a subtype is a way of placing
restrictions on the acceptable values that an object can have. In the
sense that it limits what a type can do, it's more akin to what you'd
call a supertype.
--
Jonathan "Dataweaver" Lang
