Jonathan S. Shapiro wrote:
> Concerning mutability, the variant that we are considering at the moment
> is:
>
> An aggregate value is mutable exactly if it is mutable at all
> shallow constituent fields (this definition applies recursively).
>
> The programmer is free to write mutable explicitly in this case,
> but it will always be inferred if not written.
>
> Otherwise, MUTABLE remains a type constructor in much the way that
> it is today.
The first rule is very intuitive in the case of product types (arrays
and unboxed structures) but I think is not as intuitive in the case of
sums (unboxed defunion),
In the case of defunion, should the union itself be mutable only if all
shallow fields in all legs are mutable? That is, if we have the union:
(defunion U1:val
(C1 i:(mutable int32))
(C2 j:(const int32)))
(let ((p C1))
...
(set! p C2)) ;; ERROR,
;; p cannot have type (mutable U1) since
;; it could be a C2 with a const field.
First, unboxed unions can only be updated as a whole. In the case of the
expression
(switch x e:U1
(C1 ...)
(C2 ... x.j := 25 ... ))
since x is a _copy_ of the de-constructed value of e, the update at x.i
does not affect e. The updates to x are only useful for the computation
within the C2 case. This seems to imply that the mutability of fields in
constructor legs of unboxed unions is of limited utility. However,
mutable fields in constructor legs of boxed unions are very useful.
The location storing the value of i (in the case of C1) and j (in the
case of C2) has a mutable or immutable type as distinguished by the
constructor's tag. The type (and mutability) of the location holding i
and j is permitted to safely change during program execution. Therefore,
it is safe to say that in the case of unboxed unions, the union itself
can be mutable regardless of the mutability of the fields in the
constructor legs.
The present rule (which says that the union is mutable if all
constructors only have mutable fields) might not be too bad in practice.
But, it seems unintuitive since it creates an artificial relation
between the mutually exclusive constructor legs.
Swaroop.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
