For Mvars, concurrency probably comes into play. Or at least, before we did a readMvar primop it was made out of a take and put, so even through the read prim doesn't write and doesn't block other readers, we still want to treat it's ordering as through it has a write like side effect (Edward yang can probably better opine than I on that one )

On Fri, Mar 10, 2017 at 5:17 PM David Feuer <david@well-typed.com> wrote:

Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says

> A primop "has_side_effects" if it has some *write* effect, visible
> elsewhere
>
> - writing to the world (I/O)
> - writing to a mutable data structure (writeIORef)
> - throwing a synchronous Haskell exception
>
> [...]
>
> * NB3: *Read* effects (like reading an IORef) don't count here,
>
> because it doesn't matter if we don't do them, or do them more than
> once. *Sequencing* is maintained by the data dependency of the state
> token.

But this does not actually seem to match what goes on in primops.txt.pp. The
following, among many other seemingly read-only operations, have
has_side_effects = True:

readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#,
unsafeThawArray#, tryReadMVar#, deRefWeak#

So what's the correct story? Do we want to change the note, or change the
reality? The reason I happen to be looking at this is that I think the current
arrangement allows us to define unsafeInterleaveIO in a particularly simple
fashion:

unsafeInterleaveIO = pure . unsafePerformIO

but that's only safe as long as the interleaved IO won't float out and get
performed before it's forced by normal IO.

But the unsafeInterleaveIO story seems much less important, in the grand
scheme of things, than making everything else run fast. If indeed it's
otherwise safe to mark these read-only ops has_side_effects=False, then I
imagine we probably should do that.

David Feuer
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs