On Fri, Oct 11, 2019, 11:08 AM Simon Peyton Jones <[email protected]> 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. > >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
