Jonathan S. Shapiro wrote:
>> 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.
>>
> 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).
>
6. This was Scott Smith's suggestion. Mutability dominates inwards in
unboxed structures, but does so explicitly, not implicitly.
That is, it is an error to have a mutable structure with any
immutable field.
For example:
(define iPair fst:(mutable int32) snd:int32)
(define ip:(mutable iPair) (10, 25)) ; ERROR because iPair has an
; immutable field.
However, if the user wrote
(define p:(mutablle (pair 'a 'b)) (10, 25))
it is legal, and the inference system will automatically infer
p:(mutable (pair (mutable int32) (mutable int32)))
> 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.
I think that this is the right solution too. I think that it is not too
hard to implement. The tricky part is to track the propagation of
mutability through constrained types more carefully.
> (define p:(mutable 'a) (pair 1:int32 #\c))
>
> then the question is whether
>
> (let ((myChar p.snd))
> ..)
>
> should cause myChar to be mutable.
myChar may or may not be mutable in this case. The inward propagation of
mutability does not affect copy semantics.
Swaroop.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
