Mutability rules

We're at a point where we need to think hard about what sort of mutability restrictions we're going to enforce in Harlan. This introduces tension between ease of compiler analysis and optimization, and language ergonomics, especially for programmers used to C-style programming. Mutation also has huge influence on whether we can guarantee safety for parallel code.

From a safety and optimization standpoint, it's tempting to disallow all mutation. Very few of our test cases use mutation currently, which means there probably wouldn't be too much pain. That said, mutation is convenient, for example, in the Mandelbrot set program. Also, Greg is working on code that makes many small changes to a matrix, which would be done most concisely with mutation.

One reasonable compromise is to allow mutation that doesn't cross kernel boundaries. Outside of kernel blocks, you are welcome to use set! and vector-set! all you want. Also, within a kernel, you could use mutation for local variables as well.

This compromise works for Mandelbrot, but it doesn't work for Greg.

Also, if we start allowing asynchronous kernels, we need to be careful about mutating data that's referenced by the kernel. The problem of referencing data between host and device code simultaneously is something we need to be careful about anyway though.

The other question is how to enforce this. The type system might be able to, but this feels more like an effect or kind system thing. Unfortunately, I don't know enough about either of these to know what to do yet. Anyway, whatever rules we come up with, we need to be sure we can enforce safety, preferably statically, but dynamic is okay too.