Trey Harris wrote:
Trey Harris writes:
> 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.
S02 already has q[A variable's type is a constraint indicating what
sorts of values the variable may contain. More precisely, it's a
promise that the object or objects contained in the variable are
capable of responding to the methods of the indicated "role".]
Incidentally, this would mean that a C<where> clause or junctive type
defines an anonymous role, and a type parameter defines a lexical role,
doesn't it? Seems like a useful characteristic of these constructs to
make explicit, perhaps in L<S12/Roles>.
IMHO, this gets it backward. You shouldn't turn C<where> clauses and
junctive types into roles; you should turn roles and junctive types
into C<where> constraints: "Foo $x" is, in effect, shorthand for
something like "$x where { .does(Foo) }", while "Foo | Bar Baz $x"
becomes something like "$x where { .does(Foo) || .does(Bar) &&
.does(Baz) }".
At its core, a type is nothing more than a constraint on the objects
that a given variable is allowed to handle; this would put C<where>
clauses at the center of the type system, with roles coming in a very
close second due to the implicit use of ".does()" in the compact
syntax. IMHO, @Larry got overly precise in the above S02 quote:
s[More precisely] = "Usually".
--
Jonathan "Dataweaver" Lang
