Jon Lang |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;


   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 and the reply.


Reply via email to