Much ado about parametric roles and their instantiations #505
Description
While trying to get some edge cases around parametric roles working in RakuAST, I've come across strong headwinds against progress. After about six weeks of solid hacking on this, I only managed a few measly improvements
(see PR#6032).
Before I spend yet further hours on this, I'd like to make sure that we have genuine agreement over how parametric and "curried" roles work, including how they look.
Appearances
Consider the following from base:
role R[::T] {
my class A is Array[T] {}; has A $.a = A.new; method aa { A }
}
dd [Int].new.aa'
# Int = R::A[Int]
When I first saw this syntax (R::A[Int]), it didn't come across as clear to me. In fact, it looked downright wrong. I would have expected R[Int]::A.
However, the above syntax is tested for explicitly in the current roast.
Was role parameterization originally spec'd to have this syntax?
Behavior
Perl6::Metamodel::ParametricRoleHOW.parameterize returns a Perl6::Metamodel::CurriedRoleHOW object. This now means three different metamodel objects are involved (because we can't forget our good friend Perl6::Metamodel::ParametricRoleGroupHOW!).
In RakuAST we rely heavily on stubbed meta objects, quite extensively in fact while creating packages (and therefore roles). I can't say for certain how much of a mess is made by having RakuAST::Role.PRODUCE-META-OBJECT return a completely different object than RakuAST::Role.PRODUCE-STUBBED-META-OBJECT does (that's actually defined on RakuAST::Package, but I'm trying to make a point here).
So there is an unknown unknown amount of mess created by this disunion.
Is there a better way to do this?
How much more should I invest in this?
Without having a clear way forward, there are only so many options available to us with regards to the foretold-in-ancient-legends release of v6.e.
I would like to clarify at which point we simply remove the generics.t files in t/ and in roast and move on with the intention of fixing it later.