TSa (Thomas Sandlaß) wrote:
There is no formally defined subtype relation or rules for subsumption.
A type is called narrower without details what that means.
A is a subtype of B if A ~~ B, where ~~ is the smart-match operator..It's up to the type object on the RHS how it responds to this. Type objects of classes take that to mean that the thing on the LHS should inherit from it, roles take it to mean that the thing on the LHS does the role, etc.

And the odering in dispatch is not a type lattice as in Cecil but a topological ordering. Again I've no clue what that means.
Take all of the candidates. Build a DAG where there's an arrow from a narrower to a wider candidate. Do a topological sort on the DAG, and you've got the ordering. Note that narrowness is a stronger condition than subtype; if A ~~ B and B ~~ A then you have two types that are tied. S12 describes how this extends from individual parameter types to give a way to determine if two signatures are tied or if one is narrower than the other.

It is possible for one role to do another as in

   role A does B {...}

and all objects that do A are also B doers. So one could infer that we
have A <: B. But note that this subtype relation is not enforced in the
body of the role or in the class it is composed into.
Can you clarify what you mean by "not enforced"? I think I'm missing something, since if you have:

role B {
   method m() { ... }
role A does B { }
class C does A { }

Then you get a composition time error (or should, by spec) because C does not implement a method "m". (Current Rakudo gets this wrong, but it's a fault of the implementation, not the spec).

The spec says nothing about class inheritance and type narrowness.
Despite both terms showing up multiple times in S12?

Parametric roles are covariant on their type parameter irrespective of its use. 
E.g. you can declare a read/write attribute of that type.
While parametric roles do fill the niche of parametric types, you can also parametrize them with values - STD (the standard grammar) takes advantage of this. In many ways, a parametric role definition works like a kind of role factory; an implementation falls quite naturally out of multiple dispatch and closure semantics. Seeing parametric roles as being solely for parametric polymorphism is casting their role in Perl 6 a little too narrowly though.

I agree that the information that is available on the Perl 6 type system is scattered across the synopses, and in some places probably needs a look at the spectests, and probably has untested edge-cases too. Maybe it'd be good to try and collect it together more at some point, so there's a single source to point people at.

Hope this helps,


Reply via email to