Re: where constraints as roles (was Re: how typish are roles)
HaloO, Jonathan Lang wrote: 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 Cwhere 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. Great idea! I like the unification of everything typish under the umbrella of (type) constraints. These predicates then need to be amenable to subsumption and entailment forming the dispatch lattice. Of course the sublanguage for where clauses has to be a restricted subset of full Perl 6. Otherwise you can't do machine proofs. This view is shared by mmd-draft.txt, it states that conceptually all dispatch relevant informations are predicates. Hmm, having regular expressions in where clauses already raises the question if one can treat them programatically. E.g. a 'where /^aa.*bb$/' is strictly more specific than 'where /^a.*b$/'. But can that be calculated in a deterministic fashion? Would dispatch at least work on a case by case basis? Or would we get ambiguity errors because of principal incomparability of the two clauses? IOW, I fear this could only be put to work with two subset declarations subset ab of Str where /^a.*b$/; subset aabb of ab where /^aa.*bb$/; and the notion that the second subset by virtue of constraining the possible values further produces a more specific subtype for dispatch. That is nominal subtyping. BTW, the above example is a good case for introducing the subtype relation operator : because we have aabb : ab : Str but do we also have aabb.does(ab) and ab.does(Str)? Could we also state that aabb () ab () Str? Regards, TSa. --
Re: where constraints as roles (was Re: how typish are roles)
TSa wrote: IOW, I fear this could only be put to work with two subset declarations subset ab of Str where /^a.*b$/; subset aabb of ab where /^aa.*bb$/; and the notion that the second subset by virtue of constraining the possible values further produces a more specific subtype for dispatch. That is nominal subtyping. Perl 6 already uses nominal subtyping: S02 - Types are officially compared using name equivalence rather than structural equivalence. There's further elaboration which addresses many of the concerns involved with using nominal subtyping, so I'd suggest reading the section in question before commenting. BTW, the above example is a good case for introducing the subtype relation operator : because we have aabb : ab : Str but do we also have aabb.does(ab) and ab.does(Str)? Could we also state that aabb () ab () Str? Regards, TSa. -- -- Jonathan Dataweaver Lang
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 Cwhere 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 LS12/Roles.
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 Cwhere
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
Ctry, perhaps by making the anonymous roles generated by Cwhere 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 Cwhere clause in the sub signature defines a different
anonymous role from the second Cwhere clause after Cbut, 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, Cwhere 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
Cwhere not participate in gradual typing? If Cwhere 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 Cwhere
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 Cwhere 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: 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 Cwhere 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 LS12/Roles.
IMHO, this gets it backward. You shouldn't turn Cwhere clauses and
junctive types into roles; you should turn roles and junctive types
into Cwhere 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 Cwhere
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: 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
