atomicModifyMutVar2

[David Feuer]

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

> David
>
> I’m deeply puzzled atomicModifyMutVar2#.  I have read the proposal
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0149-atomicModifyMutVar.rst>,
> 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.

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191011/b54069d0/attachment.html>