Mask effects on fresh data

[anonymous]

In a type like

 fun :: forall %r1 %r2
     .  Int %r1 -(!e1)> Int %r2
     :- !e1 = Read %r2

The effect Read %r2 isn't being masked by Type.Scheme because %r2 is visible in the shape of the type. However, as the data is fresh the fact that there was a read when constructing it does matter, so it can be masked.

Core.Reconstruct will need to use the closure annotations on XLam nodes to show that this is ok.

[benl]

Comment by Jared

This also causes a spurious !Write effect in primString_eq, which gets it from string_flatten. The result is that string equality can't be used as a guard to a top-level function. The following code can be used as a test case.

foo () = do
    result = newString 6
    dangerPack "effect" result
    result

The fact that there was a write doesn't matter unless the region is a shared memory space, such as a hardware register or an interprocess communication buffer. It's safe to assume by default that it isn't.

[benl]

I've found I need to use the 'copy' function to re-constify data to get around this problem. It's been more trouble now that top level data defaults to constant.

We'll need to modify the core language to fix this. I think we need a 'local' expression which overrides the mutability of a region, as long as its body doesn't contain any free variables who's types contain that region..

f = /\%r1. ... local %r1 { wm = Mutable %r1 } in EXP