On Sun, Mar 27, 2011 at 10:49 PM, Jonathan S. Shapiro <[email protected]> wrote:
> 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.
I suppose I will take the bait, I am curious to see if i will be able
to remove my head from between
the posts of the staircase.
it seems as though ImmType has a 'mutability type contstraint' of
immutable and not mutable,
while Unboxed Type has a mutability type constraint of unspecified.
presumably 'mutable or immutable',
while S1's immField has a mutability field constraint of unspecified,
and S2's immField has a mutability field constraint of immutable.
constraint
mut imm
------------------
IT 0 1
IF 1 1
------------------
& 0 1
constraint
mut imm
------------------
UT 1 1
IF 0 1
------------------
& 0 1
so they seem to me they are identical twins, deceptively similar but
not the same.
> 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?
'a 0 1
field 1 1
------------------
field&'a 0 1
thus it seems to me that field mutability must be a derivative of both
type mutability constraint and field mutability constraint, but is not
necessarily an exact reflection of either, i suppose this is what you
mean by path-stepwise?
in this model, neither the final field mutability, nor the field/type
mutability constraint may be 0 0.
(one being an internal compiler error, the other an error from the compiler).
and anything specifying 'mutable can be relaxed to immutable', must be
handled by ensuring both bits are on,
rather than attempting to remove bits.
unboxed struct S4('a) {
i : int;
field : 'a;
immutable field2 : 'a
}
where for lack of a better syntax we're looking at
unboxed struct S4('a.constraint & (0 1 | 1 1))
and initializers of S4(5.type.constraint & 1 1, someA.constraint & 1
1, immA.constraint & 0 1)
the question to use someA.constraint or someA.type.constraint in this
seems a question of if we are passing by-value or
by-contained-value(?) or by-ref?
sorry i sort of started this reply and never seemed to finish it, so
i'm just going to post it as is
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
