Mutability

24 July 2012

Generalizing inherited mutability

I have been working on a change to the definition of mutability in Rust. This is a much smaller change than my previous thought experiments, which were aimed at achieving better parameterization (those are still percolating; I think the best approach is a modified version of the latest proposal where not all types have mutability but type parameters do…but that’s a problem for another day with many complications). The goal of these changes is to enable operations like “freeze” and “thaw”.

read more →

31 May 2012

Mutability

OK, I’ve been thinking more about the mutability issue and I think I have found a formulation that I am happy with. The basic idea is that we refactor types like so:

T = M T
  | X
  | @T
  | ~T
  | [T]
  | {(f:T)*}
  | int
  | uint
  | ...
M = mut | const | imm

This no doubt looks similar to some of my other permutations. The key difference is that before I separated qualified and unqualified types. This was intended to aid with inference, but in fact it was getting me into trouble. I realize now there is a different way to solve the inference problem. But first let me back and explain what inference problem I am concerned about.

read more →

30 May 2012

Mutability idea retracted

I have been thinking a bit more about the approach to mutability I recently discussed. It seemed a bit too good to be true (too clean) and I think I’ve realized a problem.

The problem derives from my definition of types:

T = Q U
Q = mut | const | imm
U = [T]
  | @T
  | &T
  | { (f : T)* }
  | X
  | int
  | uint
  | ...

The interesting case is that of a type variable, denoted as X. I grouped type variables under the heading of “unqualified types”. But this is of course incorrect, they are not unqualified types. They can map to a qualified type (in fact, that’s the whole point of this exercise). So really the hierarchy ought to be:

read more →

28 May 2012

Moving mutability into the type

I am dissatisfied with how mutability is treated in the Rust type system. The current system is that a type is not prefixed mutable; rather, lvalues are. That is, a type T is defined like so:

T = [M T]
  | @ M T
  | & M T
  | { (M f : T)* }
  | int
  | uint
  | ...
M = mut | const | (imm)

Note that there is no type mut int (a mutable integer). This is logical enough; such a type has little inherent meaning: an integer is a value, it is not mutable or immutable.

read more →