<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
> 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.<br>
<p>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.</p>
<p>> I don't see the need for this. Users can easily force
exactly what they want using atomicModifyIORef2 (or if they really
want, atomicModifyIORef2Lazy).</p>
<p>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.<br>
</p>
<br>
<br>
<div class="moz-cite-prefix">On 2018年07月12日 13:07, David Feuer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMgWh9tKgs0znNCDSNVnBUfiBJcD06z7s5wKDBPUBotbtvsdog@mail.gmail.com">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jul 11, 2018, 11:32 PM winter <<a
href="mailto:drkoster@qq.com" moz-do-not-send="true">drkoster@qq.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">OK then,
here's some subtle things i want to shout out if you're
going to make the change ; )<br>
<br>
1. The proposed naming is just not great, how about these:<br>
<br>
atomicExchangeIORef :: IORef a -> (a -> (a, b))
-> IO (a, (a, b))<br>
atomicExchangeIORef' :: IORef a -> (a -> (a, b))
-> IO (a, (a, b))<br>
<br>
atomicApplyIORef :: IORef a -> (a -> a) -> IO (a,
a)<br>
atomicApplyIORef :: IORef a -> (a -> a) -> IO (a,
a)<br>
<br>
It may not that great but it's more informative IMO.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I agree that my names aren't great, but I think
yours are worse.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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)<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4. atomicExchangeIORef' will not only force the tuple, but
also force both `a` and `b` part to match
atomicModifyIORef' 's semantics.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I don't see the need for this. Users can easily
force exactly what they want using atomicModifyIORef2 (or if
they really want, atomicModifyIORef2Lazy).</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
5. atomicApplyIORef(and atomicApplyIORef') deserve its own
primop, since we can skip building selector thunks all
together.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
</blockquote>
<br>
</body>
</html>