Giuseppe Castagna wrote:
On 02/05/2010 11:29 PM, Jonathan Worthington wrote:
And the odering in dispatch is not a type lattice as in Cecil but a
topological ordering. Again I've no clue what that means.
and all objects that do A are also B doers. So one could infer that we
have A <: B. But note that this subtype relation is not enforced in the
body of the role or in the class it is composed into.
Can you clarify what you mean by "not enforced"?
I interpreted Thomas remark as the fact tha declaring subclass does
not enforce safe substiatability.
Am I wrong?
That was how I understood it too, provided I understand "safe
substiatability" in the same way (I figure a Perl 6 type system document
had probably better start out by defining the terms it uses :-)).
Anyway, I'd appreciate an example where Perl 6 fails to enforce what
Thomas is looking for it to, so I can grasp the problem a little better.
While parametric roles do fill the niche of parametric types, you can
also parametrize them with values - STD (the standard grammar) takes
advantage of this. In many ways, a parametric role definition works like
a kind of role factory; an implementation falls quite naturally out of
multiple dispatch and closure semantics. Seeing parametric roles as
being solely for parametric polymorphism is casting their role in Perl 6
a little too narrowly though.
I think nobody wanted to do it.
Sorry, I wasn't accusing, just trying to point out their wider, er,
role. :-)
The point is that if you add variance annontation (as in C# or Scala)
to specify where you can use the type parameters coavariantly or
contravariantly give you the same flexibility and furthermore type
safety. The PL researcher I know at Javasoft still regret to have
allowed covariance for Arrays (this is just second in the regret list,
the first being that production people did not allow them to change
the JVM to deal with generics in the bytecode).
We actually have the problem in a wider sense even without the
parametric types. Given S ~~ T:
sub foo(T $x is rw) {
$x = T.new;
}
my S $y = S.new;
foo($y);
The assignment fails here, because the container $y requires an S, and
won't accept a T. So essentially Perl 6 currently has the same approach
to things as e.g. C# does for its arrays since they are covariant - a
runtime check. This case certainly has come up before in Perl 6 design
discussion.
We may be able to work variance annotations into Perl 6 somehow. I'd
kinda expect them to be "first class" and essentially be something like
a more constrained version of the more general type (in that you can use
it in less ways). We may be able to hack something up that approximates
the semantics that is essentially a wrapper around an existing type
object. I'm too tired to get this right, but you'd maybe stub it a bit
like...
class COVTYPE {
has $.T handles *;
method new($T) { self.bless(T => $T) }
method ACCEPTS($subtype) {
# checking algorithm here
}
method defined() { False }
}
I'm kinda too tired to think about this much further tonight though (and
probably even to have thought this far :-)).
I agree that the information that is available on the Perl 6 type system
is scattered across the synopses, and in some places probably needs a
look at the spectests, and probably has untested edge-cases too. Maybe
it'd be good to try and collect it together more at some point, so
there's a single source to point people at.
This is exactly my problem. I decided to post here after spending a
couple of days just trying to understand what the precise syntax of
types is in Perl6.
Hope this helps,
Yes. Actually the best source of information on types I found is your
FAQ, that I was reading when I received your mail. Centralizing the
information there would be much useful ... at least for me.
I should probably review and maybe update that FAQ a bit, but something
more precise and complete and in the same repo as the specs would also
be good. If I get time, I may take a crack at it sometime soon.
Thanks,
Jonathan
