Optimize variants of getRef ref >>= body

[emwap]

These optimizations will rewrite expressions binding the result of getRef
by substituting the reference for the bound variable when it is morally safe to do so.

The rewrite is not possible in the typed representation since the reference
and the bound variable have different types.

/cc @pjonsson, @emilaxelsson

[pjonsson]

I spent 10 minutes looking at the patch and thinking about this and I don't feel good about it. I don't have time to figure this out on my own this week so can you specify the intuition for when the substitution is morally safe?

The code uses fv and the comment talks about free. Using "not in" instead of "free" in the comment would be more clear.

[emwap]

You are absolutely correct. I will update to "not used in".

[emwap]

I have updated the comments. The reasoning is that if the reference itself is not used in the body the we do not need to copy the data into a new variable.

[pjonsson]

cc @josefs

Oh, uhm, a syntactic condition for approximating single use. I cc'd the resident linear typist. "What about scope extrusion?" was the first thing that came to my mind. Either way, I'm swamped right now so instead of stalling you--go ahead and merge unless you find something else that is wrong with these patches. We'll keep an eye out for weird behaviour with mutable references.

[josefs]

@pjonsson not sure what you mean wrt scope extrusion here. I don't see how that comes in to play at all.

As for having an intermediate language which somehow tracked linearity/affinity, that would be awesome. But I have yet to see a compelling design which is practical.