> > > This certainly suggests to allow the export of an immutable view of a
> > > record type with mutable fields. This way you could do the
> Alas, it can do a lot of harm. For one thing, you could break type
> safety this way, just like with polymorphic references:
[...]
> So, no, we can't allow exporting a record with different mutability
> annotations than in its definition.
This is perfectly right, and as always with mutable values, you cannot
implement a feature without adding some safeguard conditions.
That's why I suggested to export an immutable VIEW of a record type
with mutable fields, not simply to export it as an immutable type!
I was thinking of something like:
type 'a loc = {mutable contents : 'a} as {contents : 'a};;
This way the compiler knows everything about the type, the original
and ``view'' definitions, so that nothing can be invalidated. The gain
is that now, direct assignment as
x.contents <- value
is forbidden, and values of loc cannot be assigned outside their
definition module, if this module carefully avoids to export any
assignment function.
Evidently, values of type ref should be considered mutable by the
compiler, for instance during the constant propagation pass.
This view conception of type exportation could also be generalized to
hide some other information about a type to export: hide some
constructors or labels...
-- Pierre WeisINRIA, Projet Cristal, http://pauillac.inria.fr/~weis
This archive was generated by hypermail 2b29 : Mon Apr 10 2000 - 02:07:06 MET DST