HaloO,
Luke Palmer wrote:
Removing abilities, counterintuitive though it may seem on the
surface, makes the type *larger*. It is not adding constraints, it is
removing them (you might not be able to call set($x) on this object
anymore).
Welcome to the co- and contra-variance problem again. We must
distinguish two sets:
(1) the set of all conceivable instances
(2) the set of constraints
Larry means (2) while Luke is talking about (1) in the
particular case of record subtyping I think. That is
methods are arrow typed slots of the object record (That is
they have type :(Object --> ::X --> ::Y)). Interestingly Perl6
doesn't provide a sound sublanguage for defining constraints
in a way that is amenable for predicate dispatch. I would
expect the where blocks to be under very strict control of the
type system but seemingly they aren't.
In order to resolve the linguistic conundrum of "when Array", we could
say that the Array role in fact implements a constant Array. If you
would like to be a mutable array, you implement MutableArray or
something. That would make code like this:
given $x {
when Array { $x[42] = 42; }
}
broken from a pure point of view. You may not be able to set element
42 of that array. Perl would still allow the code to compile, of
course, because Perl is a laid-back language.
The point is that reference types are co-variant for reading and
contra-variant for writing. The only escape for rw access is mandating
type equality which in Perl6 comes as 'does Array' and has got the
rw interface.
Constness is something that exists, so we have to solve it somehow.
Yes, but it's only half the story! The other thing that has to be
solved is writeonlyness. Both in isolation result in type soundness
in the presence of subtype directed dispatch. But both at the same
time lose this and mandate type equality.
Note that a rw Array is nicely applicable where either a readonly
or writeonly subtype is expected. The only difference is in the
return type handling, of course! Also sharing parts of the Array
implementation is orthogonal to the question of subtyping.
But
pretending that const arrays are arrays with the added capability that
they throw an error when you try to write to them is going to get us
to a broken type model.
I think type inference should be strong enough to find out that
an Array parameter of a sub is consistently used readonly or writeonly
and advertise this property accordingly to the typechecker and the
dispatcher.
Regards,
--
