TSa wrote:
I want to summarize what we have so far.
1) In type constraint position we can say things like A|B to effectively
mean a supertype of A and B by virtue of $_ ~~ A || $_ ~~ B.
Right. This would be equivalent to "Any where {.does(A) or .does(B)}".
2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
which is an intersection (sub)type of A and B.
Not according to my reading of S06: if you want to force a parameter
to match both of two different roles, you must use a where clause.
3) The junctive ops |, & and ^ can be used in where clauses to form
type constraints. How does that apply to any(), all(), one() and
none()? Are they allowed as well? With none() we effectively get
type complement.
AFAICT, any() can be used (almost) anywhere that infix:<|> can be;
ditto with the other junctive ops and their associated functions. In
particular, I see no reason why they would be forbidden in where
clauses. (The one case where "any" might not be usable as a
substitute for infix:<|> is point 1, above. Even then, I'm not really
certain that it can't be used.)
4) The junctive ops and the set operators (|) and (&) are *not* yet
available as type constructors in role definitions, that is things
like 'role does A(&)B'.
Correct. If there's a queue being maintained for post 6.0 features,
I'm hoping that it's in the queue; but it isn't going to be a 6.0
feature AFAIK.
Does recursive use of roles in their own definition produce F-bounds?
role A does Gen[A] {...}
I don't see why not. Heck, while it would usually be silly to do so,
I could even see cyclic role definitions working:
role A does B { ... }
role B does A { ... }
or even
role A does A { ... }
(though why any role would ever want to compose itself is beyond me.)
--
Jonathan "Dataweaver" Lang
