On Tue, Dec 23, 2014 at 12:07 PM, Geoffrey Irving <[email protected]> wrote:
> For my benefit and possibly others, here's the lattice structure written > out: > > mutable -- read-only ----- immutable > \ | | > \ | | > deep-readonly -- deep-immutable > > It isn't a complete lattice, so for type inference niceness we may end > up wanting immutable && dead-readonly. > Lattice structures really benefit from directional arrows. :-) But perhaps more important, this lattice isn't right. "Read Only" means "I can't [shallowly] mutate through this alias, and I don't know whether others can or not." So from this we would conclude that 1. top-level immutable, read-only, and immutable are copy compatible 2. REF MUTABLE can be passed where a parameter of type REF READONLY is required. 3. REF IMMUTABLE can be passed where a parameter of type REF READONLY is required. or more generally: READONLY <: MUTABLE READONLY <: IMMUTABLE REF READONLY <: REF MUTABLE (as expected) REF READONLY <: REF IMMUTABLE (as expected) We can only pass a [shallow] MUTABLE to an IMMUTABLE parameter because they are copy compatible. And then we have: DEEP READONLY <: DEEP IMMUTABLE DEEP READONLY <: DEEP MUTABLE DEEP READONLY <: READONLY DEEP READONLY <: IMMUTABLE DEEP READONLY <: MUTABLE This stuff is tricky. There are a lot of things we might be tempted to justify by subtyping that are actually justified by copy compatibility. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
