TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
Jon Lang wrote:
I'm having some difficulty understanding the business with £. I
_think_ that you're saying that £ sort of acts as a prefix operator
that changes the meaning of the type with which it is associated; and
the only time that a change in meaning occurs is if the type in
question makes use of ::?CLASS or a generic parameter.
The difference seems to be the two definitions of bendit
sub bendit (IBend ::T $p -->T)
{
IBend $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;
}
The interesting thing that is actually left out is the return type
of get_something. I think in both cases it does the IBend role but
in the second definition it is checked against the actual type T
which is Thingie if called with a Thingie for $p. So the advantage
of this code is that the compiler can statically complain about the
return type of get_something. But I fail to see why we need £ in
the signature to get that.
In the top example, merge has to be declared with invariant parameter
types, so the actual type passed "isa" IBend. That means merge's
parameter is IBend. If get_something returned the proper type, it would
be lost.
In the lower example, the merge parameter is allowed to be covariant.
The actual type is not a subtype of IBend. The parameter to merge is
checked to make sure it is also T. The £ means "use the higher-order
£ike-this" rather than "isa" substitutability.
The issue is how to give covariant parameter types =and= minimal type
bounds for T at the same time.
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.
--John