My only initial reservation was it being subsumed by mutable structs. But if it's small, self contained, already implemented, and doesn't increase complexity -- why not? On Thu, Jul 5, 2018 at 3:03 PM Simon Marlow wrote:

On 5 July 2018 at 16:24, Simon Peyton Jones wrote:

...

It sounds good to me – I have not dug into the details but it seems to have had enough scrutiny.

Note that it *replaces one primop with another*, with the old one being re-defined as an ordinary function for back-compat. The proposal does not just add an extra primop. Right?

Yes, that's right.

Simon

...

I’m supportive, albeit not very well informed.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Simon Marlow *Sent:* 04 July 2018 10:19 *To:* ghc-steering-committee@haskell.org *Subject:* [ghc-steering-committee] Replace atomicModifyMutVar# (#149), recommendation: accept

https://github.com/ghc-proposals/ghc-proposals/pull/149 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F149&data=02%7C01%7Csimonpj%40microsoft.com%7Caf6991e741df405fd5a308d5e18f477f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662927862631135&sdata=biPMT2Nj9w7jJHUSdHU3eaHMS9wOzIbm7w%2B6txXLpeE%3D&reserved=0

This proposal is essentially an optimisation to the atomicModifyMutVar# primitive. I won't repeat the details here, but it amounts to moving one of the thunks produced by atomicModifyMutVar# out of the primop and into the atomicModifyIORef wrapper. The advantage is that in the case of the strict version of the wrapper, atomicModifyIORef', this extra thunk is eliminated entirely, rather than being created by the primop and then immediately evaluated by the wrapper.

I propose we accept the proposal to add the new primop in section 2.1, along with the straightforward additions proposed in sections 2.2 and 2.3. (the old primop will be removed, but can be defined in GHC.Exts as a wrapper around the new primop for backwards compat)

However, the additions to the Data.IORef library should be considered by the libraries committee separately. (there are naming issues to be resolved in particular).

Cheers

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee