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, --