So I started a note intending to ask where mutability constraint annotations
should be allowed, and investigating various options. It was *amazing* how
fast I ran into cases where two completely reasonable understandings led
immediately to conflicts. All cases below are shallow unless otherwise
noted, and I'm only considering unboxed types. So consider the difference
(if any) between S1 and S2.
immutable unboxed struct ImmType {
j : int
}
unboxed struct UnboxedType {
j : int
}
unboxed struct S1 {
i:int;
immField : ImmType; //???
};
unboxed struct S2 {
i : int;
immutable immField: UnboxedType;
};
There are a bunch of issues here.
The first is defining the "scope" of immutability. In abstract, we don't
need the entire structure to be constrained by immutability, but we
certainly need any unboxed path leading to immField (in either S1 or S2) to
obey that constraint. Which raises the question: do we need to introduce a
notion of "path-stepwise" mutability, and if so, do we need to make that
first-class so that composition works correctly?
If you want to play with this, consider what happens when we get:
unboxed struct S3('a) }
i : int;
field : 'a;
}
if 'a has immutable type, what happens?
This is the sort of issue that we need to decide and/or reconcile.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
