Ticket #23 (new enhancement)

Opened 6 years ago

Last modified 6 years ago

Mask effects on fresh data

Reported by: anonymous Owned by:
Priority: project Milestone:
Component: Source Type Inferencer Version:
Keywords: Cc:

Description

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.

Change History

Changed 6 years ago by 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.

Changed 6 years ago by 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 
Note: See TracTickets for help on using tickets.