Discussion: New atomic IORef functions

[winter]

 > I generally disagree. Being lazy in the tuple is pretty much an 
invitation to memory leaks. I think the lazy version should ideally also 
be available (it's what the new primop will provide, after all), but I 
don't think it should be the obvious thing for people to reach for.

let's put lazy modifying cases aside(which is not that rare), I'm pretty 
sure haskell forks will use strict version from time to time, it's not 
the lack of ' make a funtion more easy to reach, it's really just a 
matter of document,  why breaking consistency with original 
atomicModifyIORef/atomicModifyIORef'  ? I expect the old mnemonic still 
works on new ones.

 > I don't see the need for this. Users can easily force exactly what 
they want using atomicModifyIORef2 (or if they really want, 
atomicModifyIORef2Lazy).

Exactly the same reason with above, if people have to force the a and b 
part to stop leakage, then this strict version is not really doing a 
good job IMHO, I just don't see the value that you have already forced 
the modification function, but then stopped at a half place where left a 
thunk inside the IORef.



On 2018年07月12日 13:07, David Feuer wrote:
> On Wed, Jul 11, 2018, 11:32 PM winter <drkoster at qq.com 
> <mailto:drkoster at qq.com>> wrote:
>
>     OK then, here's some subtle things i want to shout out if you're
>     going to make the change ; )
>
>     1. The proposed naming is just not great, how about these:
>
>     atomicExchangeIORef :: IORef a -> (a -> (a, b)) -> IO (a, (a, b))
>     atomicExchangeIORef' :: IORef a -> (a -> (a, b)) -> IO (a, (a, b))
>
>     atomicApplyIORef :: IORef a -> (a -> a) -> IO (a, a)
>     atomicApplyIORef :: IORef a -> (a -> a) -> IO (a, a)
>
>     It may not that great but it's more informative IMO.
>
>
> I agree that my names aren't great, but I think yours are worse.
>
>
>     3. atomicExchangeIORef should not force the tuple, e.g. don't
>     pattern match on the tuple result, instead let users choose to
>     force or not. (May worth adding some document, I'd be happy to help)
>
>
> I generally disagree. Being lazy in the tuple is pretty much an 
> invitation to memory leaks. I think the lazy version should ideally 
> also be available (it's what the new primop will provide, after all), 
> but I don't think it should be the obvious thing for people to reach for.
>
>
>     4. atomicExchangeIORef' will not only force the tuple, but also
>     force both `a` and `b` part to match atomicModifyIORef' 's semantics.
>
>
> I don't see the need for this. Users can easily force exactly what 
> they want using atomicModifyIORef2 (or if they really want, 
> atomicModifyIORef2Lazy).
>
>
>     5. atomicApplyIORef(and atomicApplyIORef') deserve its own primop,
>     since we can skip building selector thunks all together.
>
>
> Yes, I've implemented that primop already, and it will be added. I'm 
> still looking for an expert to help implement the simplest of the lot, 
> atomicSwapMutVar#, as efficiently as possible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180712/ec41f740/attachment.html>