Larry,
On Oct 14, 2005, at 1:28 PM, Larry Wall wrote:
Generics are somewhat orthogonal to the mutable/immutable distinction,
except that they're a better fit for roles because someone has to
choose when to instantiate them, and they're easier to understand
with early binding rather than late binding. So another way to view
the role/class distinction is that roles have eager semantics while
classes have lazy semantics. I expect it's possible to do lazy
generics, but I would put it in the category of hard things that
should be possible.
I am not 100% sure what you mean by "lazy" generics vs. "eager"
generics. But in the current metamodel prototype I have implemented,
what I believe to be, "lazy" generics. It works like so.
Say we have a generic Unit class, which needs a type (::T) for it's
value:
class Unit[::T] {
has ::T $.value;
}
Now I am assuming that a class body is a closure (which surely it is)
and that it usually just gets evaluated right away. What if we defer
that evaluation?
Lets de-sugar the above example a little:
my $Unit = sub (::T) {
class Unit[::T] {
has ::T $.value;
}
};
Now we have not yet actually created any Unit classes yet (generic or
otherwise). Instead we have a closure which given the right set of
parameters, can create specific instances of the Unit class which are
parameterized.
Now we create our Unit[Int] class like this:
my $unit_int = Unit[Int].new();
Which would be just sugar for this:
my $unit_int = $Unit.(Int).new();
Again, I am not sure if this is what you mean by "lazy" generics or not.
Stevan
