Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
Perhaps it would be clearer if you could illustrate the difference between
sub bendit (£ IBend ::T $p -->T)
{
T $q = get_something;
my T $result= $p.merge($q);
return $result;
}
and
sub bendit (IBend ::T $p -->T)
{
T $q = get_something;
my T $result= $p.merge($q);
return $result;
}
Or perhaps it would be clearer if I actually understood what
"covariant" means.
The use of £ in
sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType)
is that of *structural* subtyping. Here FoxPoint is found to be
pointlike. In that I would propose again to take the 'like' operator
from JavaScript 2. Doing that the role should be better named Point
and foo reads:
sub foo (like Point ::PointType $p1, PointType $p2 --> PointType)
This is very useful to interface between typed and untyped code.
With rthe 'like' the role Point has to be *nominally* available
in the argument. There's no problem with 'like'-types beeing more
expensive than a nominal check.
Yes, with Point would work for matching as well as pointlike. When the
covariant parameter type destroys the "isa" relationship between Point and
Point3D, "£ Point" will still indicate conformance to the "like" rules.
I like "like" as the ASCII synonym to £, but didn't want to get into that
in the whitepaper. I wanted to concentrate on the need for a higher-order
type check, not worry about how to modify the grammar.
OK; how does "higher-order type checks" vs. "isa relationships" differ
from "duck typing" vs. "nominal typing"?
I think I see another whitepaper in my immediate future.
And to think I was asking the same question ("what is covariant") on
this mailing list less than a month ago! See
http://www.nntp.perl.org/group/perl.perl6.language/2008/04/msg28845.html
and the reply.
--John
