Re: how typish are roles
On Wednesday 25 October 2006 03:04, Trey Harris wrote: > I'll let @Larry speak for @Larry, but at one point I was told that when > C or C appear in signatures, those are roles, not classes; if > you examined a particular Array or Hash, the class would be some > implementation of the Array or Hash role, perhaps something like > C or C or so on. So I'd tend to agree > that roles "are the heavyweights in the type department." Yes. When you specify a type to constrain some operation, you specify that the target entity must perform that role. > Unless you're actually composing or inheriting from something, you > shouldn't care whether its type derives from a role, a class, a type set, > or a type parameter. Yes. > 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. > I can read S12 as saying that classes always do an eponymous role, and so > role is what typing is "really" based on. Yes. > In other words, I agree that it's fuzzy, but I personally read the > fuziness as intentional, so as to allow implementations flexibility and > prevent bad dependencies on particular "inner workings" of the type > system. That fuzziness is classic $Larry. Some of the rest of @Larry can be more *mumble*matic. -- c
Re: how typish are roles
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
where constraints as roles (was Re: how typish are roles)
In a message dated Sat, 28 Oct 2006, Trey Harris writes:
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.
Incidentally, this would mean that a C 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.
I find this a little unintuitive given the way these typing particles are
used, though... If I were insane in a different way than I actually am, I
might think I could use this "every constraint is a role" behavior to
write:
sub pairs_up_to (Int $x where { $^x % 2 == 0 } ) {
(1..^$x:by(2)) >>=><< (2..$x:by(2))
}
pairs_up_to(4)};# 1 => 2, 3 => 4
try { pairs_up_to(3) }
err say $!; # "No compatible subroutine found"
my $even_three = 3 but where { $_ % 2 == 0 }; # Huh?
try { pairs_up_to($even_three) }
err say $!;# What?
Not a useful example, I admit--which is why I had assumed C
constraints were not roles, because I can't think of a useful example of
treating them as roles. But I suppose if you're determined to shoot
yourself in the foot like that, you'll find some way (like overloading
C<%> so it always returns 0).
You could probably even make Perl be able to call the sub in the second
C, perhaps by making the anonymous roles generated by C first
match by AST equivalence before testing their value against the constraint
or something.
Not that I think Perl should be able to do that... I'm just saying I
*might* think it would, given how roles usually work (and if I could come
up with a less contrived case, I might actually expect it to).
But *why* wouldn't it work? One of two reasons I think:
1. The first C clause in the sub signature defines a different
anonymous role from the second C clause after C, even
though they're defined identically. In that case, $even_three would
have no practical difference from any other 3, because it merely mixes
in a role that never gets used.
2. The assignment would throw a mistyped value exception, just like
"my Num $foo = 'hi, mom'" does. (Except it doesn't. Should it? I
don't see a test that addresses this in the suite, nor something in
the Synopses to say that that assignment should fail.)
In either case, C clauses create roles that values might do without
even realizing they're doing them, and which mutable objects might do and
then not do, willy-nilly, even in the course of the scope in which they
were typed to do it... which I think is new unless I just haven't been
paying attention.
sub saturate (Color $c where { $^c.saturation < 100 } ) {
$c.saturation = 100; # ???
correct_gama($c);
}
Did that mutation throw an exception, by changing $c's type to one it
can't have in this sub? If no, did we just lose gradual typing (assuming
correct_gamma cares)? Can we detect that, or do the roles created by
C not participate in gradual typing? If C constraints
weren't roles, this would make sense to me again.
It's duck-typing, but a very different type of duck typing than, say Ruby
has... it isn't a duck because it walks and quacks, but because when you
examine it with your particular duckish litmus test (your C
clause), the litmus test turns the duckish color (Bool::True) you're
looking for.
A trifling issue, I guess, as you can just ignore how C works so
long as it does work. But when I see a statement like "every X is really
syntactic sugar for a Y", I want to poke at all the X's to see how they
behave deeply as Y's.
Trey
Re: where constraints as roles (was Re: how typish are roles)
My initial inclination is to say that "where" clauses in a signature are only there for pattern matching, and do not modify the official type of the parameter within the function body. However, on a "subset" the "where" clause is there precisely to contribute to the typing, so if you want the extra constraints to apply to all uses of the parameter variable within the body, you'd need to declare a subset type that enforces it. On the other hand, I can imagine that an alternative would be to say that a "where" clause will always "subsetize" the official type; that would imply that we'd need to add a "when" clause for mere pattern matching. Something to be said for making such a distinction, if it can be taught. Fuzzily yours, Larry
Re: how typish are roles
On Thu, Oct 26, 2006 at 03:17:27PM +0200, TSa wrote: : HaloO, : : I wrote: : >2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B : > which is an intersection (sub)type of A and B. : : Is the A&B form a legal alternative for the juxtaposition? Not in a signature. It's ambiguous with A &B where &B is declaring a routine type that returns A. Might be made to work in parens someday. But I'm still somewhat set against the notion of using logical ops to do set theory. (Even if you put parens around them.) Larry
Re: where constraints as roles (was Re: how typish are roles)
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 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.
IMHO, this gets it backward. You shouldn't turn C clauses and
junctive types into roles; you should turn roles and junctive types
into C 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
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
Re: how typish are roles
Larry Wall wrote: But I'm still somewhat set against the notion of using logical ops to do set theory. (Even if you put parens around them.) Understandably so. Perhaps "(u)" and "(n)" would be better ASCII equivalents for the union and intersection operators... -- Jonathan "Dataweaver" Lang
Re: where constraints as roles (was Re: how typish are roles)
On Saturday 28 October 2006 09:15, Larry Wall wrote: > My initial inclination is to say that "where" clauses in a signature > are only there for pattern matching, and do not modify the official > type of the parameter within the function body. However, on a "subset" > the "where" clause is there precisely to contribute to the typing, > so if you want the extra constraints to apply to all uses of the > parameter variable within the body, you'd need to declare a subset > type that enforces it. Right; it's awfully difficult to have nominal typing in a room full of blank "Hello my name is" tags. > On the other hand, I can imagine that an alternative would be to say > that a "where" clause will always "subsetize" the official type; > that would imply that we'd need to add a "when" clause for mere > pattern matching. Something to be said for making such a distinction, > if it can be taught. -- c
