On Fri, Oct 11, 2019, 11:08 AM Simon Peyton Jones <simonpj@microsoft.com> wrote:

David

I’m deeply puzzled atomicModifyMutVar2#.  I have read the proposal, and the comments in primops.txt.pp (reproduced below).

Question 1

I think the “real” type of atomicModifyMutVar2 is

atomicModifyMutVar2# :: MutVar# s a

                     -> (a -> (a,b))

                     -> State# s

                     -> (# State# s, a, (a, b) #)


Close, but not quite. The result doesn't have to be a pair. It can be a tuple of any size at all. Indeed, it can even be an arbitrary record type whose first pointer field has the appropriate type.

Nowhere is this explicitly stated, but I believe that the intended semantics of a call

case (atomicModifyMutVar2# mv f s) of (# s’, x, r #) -> blah

Then, suppose the old value of the MutVar was ‘old’

  • The primop builds a thunk  t = f old
  • The new value of the mutable variable is (fst t)
  • The result r is t
  • The result x is old

Question: is that correct?   We should state it explicitly.

Yes, that sounds right.

Question 2

Next question: Why does f have to return a pair?  So far as I can tell, it’s only so that a client can force it.   The ‘b’ part never seems to play a useful role.   So we could equally well have had

atomicModifyMutVar2# :: MutVar# s a

                     -> (a -> Box a)

                     -> State# s

                     -> (# State# s, a, Unit a #)

where Unit is defined in Data.Tuple

    data Unit a = Unit a

Now you can force the result of (f old), just as with a pair.  But the ‘b’ would no longer complicate matters.

Question: is the ‘b’ in the pair significant?   Or could we use Unit?

Yes, it's somewhat significant. You actually can use Unit with the new primop (it's a tuple of arity 1), so that option is free. But using a pair gets you a bit more: you can build a thunk that's *shared* between the value installed in the MutVar and the one returned to the outside. Consider

atomicModifyMutVar2# mv $ \a ->

  let foo = expensive_computation a

  in ([3,foo], foo)

Question 3

In the comments below you say "but we don't know about pairs here”.   Are you sure?  What stops you importing Data.Tuple into GHC.Prim?   This fancy footwork is one more complication, if it could be avoided.

That whole regime came before my time, but since we win a bit by *not* fixing it, o wouldn't jump on it too quick.