In a message dated Sat, 28 Oct 2006, chromatic writes:
When you specify a type to constrain some operation, you specify that
the target entity must perform that role.
That statement is very concise and direct. If the fuzziness I observed
about the identity of the basic building block of type was unintentional,
this statement should be added to S06.
I think the question (which you didn't directly raise, but I've heard
from others) of whether "role" or "class" will have primacy is kind of
as pointless as asking whether "subroutines" or "code blocks" have
primacy: you can't use the former without the latter; the former is a
useful abstraction for the latter, especially when code gets larger or
is meant for sharing; and while each have places where they're more
appropriate, either can be used in place of the other given a bit of
syntactic twiddling.
Well... maybe. I believe strongly that you can build a really good
system with roles as the fundamental abstraction and where classes are a
specialization, but doing the other way around is much more difficult
and less cohesive.
But I wasn't suggesting that, any more than I was suggesting that code
blocks based on anonymous subroutines would be as cohesive as subroutines
based on code blocks. I was just saying that both roles and classes could
be equally first-class participants in the type system by my reading of
S06 and S12: I don't see any necessity, short a statement like yours I
quoted above, for classes to be coerced into a role before they can act as
a type.
Trey
