[bitc-dev] Immutability and by-ref

[Jonathan S. Shapiro]

On Sun, 2008-07-20 at 17:12 -0400, Swaroop Sridhar wrote:
> There are a couple of ways to fix this problem:
> 
> 1) Handle it at by-ref: Declare that mutability propagates pathwise
>     while creating a by-ref. That is, the field qref^.snd can only be
>     passed as the actual parameter to a function that expects
>     (by-ref (mutable int32)). This will still forbid an assignment
>     like (set! qref^.snd 25).
> 
> 2) Declare that mutability propagates pathwise: Same as (1) except that
>     assignment to qref^.snd is also permitted. Mutability propagates upto
>     the current level of unboxed-ness.
> 
> 3) Declare that immutability propagates pathwise: The dual of (2) where
>     a field can be set (or passed as a (by-ref (mutable t)) parameter)
>     only if it is mutable as a whole as well as at the field


Option 4: prohibit field-granularity mutability, restricting mutability
to appear solely at outermost boxes, and defining that to apply to all
unboxed fields up to a ref boundary. Perhaps this is merely a stronger
re-statement of your point (2).

Option 5: prohibit inner by-ref.

I only mention these for completeness of discussion.


My personal preference is that mutability should be defined path-wise.
Prohibiting mutation on an inner, immutable field that is part of a
larger mutable cell merely imposes a copy burden on the compiler and the
programmer.

This preserves our ability to specify a "mostly init-once" structure
with selected mutable fields, but eliminates the mutability
inconsistencies that arise from inner references.

Is this a pain to do?