On Mon, 2008-07-21 at 10:45 -0400, Swaroop Sridhar wrote:
> 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.
Making this an error is too strong. Here is the problem:
On the surface, we have a "common sense" violation in the current type
system under two conditions:
1. mutable value containing immutable field
2. immutable value containing mutable field
The first one truly is a common sense violation, but the second one is
not. More precisely, the current type system gives us the ability to
express:
2a. immutable value containing immutable field (i.e. field is
init-once)
2b. immutable value containing mutable field (i.e. field is mutable).
The problem we have is that the ability to express init-once fields
implies the ability to express (1). Given which, we have two choices:
Option 1: Resolve the problem by defining some sort of rational
meaning for case (1).
Option 2: restrict mutability to outermost values.
The problem is that init-once fields are important, not least because of
the requirement for union tag stability.
That leaves us with option 1, which can be resolved by defining
mutability as mutability by path. The main reason that I did not do that
in the first place was the intentional desire to discourage the use of
mutable idioms. I think, in hindsight, that once the language admits
state it is an impediment to usability to discourage mutable idioms.
I still think that my decision about making /mutable/ the keyword
(rather than /immutable) was the right call -- if we want to build
robust stuff, we need to encourage value-stable programming idioms. But
I also think that mutability is inevitable, and your path-based rule may
turn out to be a good pragmatic compromise.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
