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? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
