[bitc-dev] Immutability and by-ref
Jonathan S. Shapiro
shap at eros-os.com
Sun Jul 20 20:38:11 CDT 2008
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
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?
More information about the bitc-dev