<div dir="ltr">I also have found need for what I think you are describing but only in the context of transactional arrays where there are multiple fields to initialize while I know that the array is private to the creating thread.  For now I'm adding the primitives I need as I go, but I would like to have better safer story.  You might be interested in how the stm-containers package uses ST to build internal nodes in transactions [1], [2].<div><br></div><div>[1]: <a href="https://github.com/nikita-volkov/stm-containers/blob/master/library/STMContainers/HAMT/Nodes.hs#L36">https://github.com/nikita-volkov/stm-containers/blob/master/library/STMContainers/HAMT/Nodes.hs#L36</a></div><div>[2]: <a href="https://github.com/nikita-volkov/stm-containers/blob/master/library/STMContainers/WordArray.hs#L118">https://github.com/nikita-volkov/stm-containers/blob/master/library/STMContainers/WordArray.hs#L118</a></div><div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 8, 2016 at 10:43 PM, Thomas Koster <span dir="ltr"><<a href="mailto:tkoster@gmail.com" target="_blank">tkoster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi friends,<br>
<br>
I have an STM transaction that needs some private, temporary state.<br>
The most obvious way is to simply pass pure state as arguments, but<br>
for efficiency, I would like this state to be some kind of mutable<br>
array, like STArray.<br>
<br>
I know, STM has TVars and TArray, but since this state is private to<br>
the transaction, I am wondering if using TVars/TArrays for private<br>
state might be overkill that will unnecessarily slow down the STM<br>
commit process. The private state is, by definition, not shared, so<br>
including it in the STM log and commit process is, as far as I can<br>
tell, pointless.<br>
<br>
ST and STArray still appear to be the most appropriate tools for the<br>
private state, because STRefs and STArrays really, really are private.<br>
<br>
So this basically means I want to interleave ST and STM in a "safe"<br>
way. That is, if the STM transaction retries, I want the ST state to<br>
be vaporised as well.<br>
<br>
Ideally, I would love to be able to say something like this:<br>
<br>
-- | Copy the value from the shared TVar into the private STRef.<br>
load :: TVar a -> STRef a -> STSTM s ()<br>
load shared private = do<br>
  value <- liftSTM (readTVar shared)<br>
  liftST (writeSTRef private value)<br>
<br>
Naturally, that STRef must originate from a call to newSTRef earlier<br>
in the same transaction and is private to it, just like the real ST<br>
monad. As far as I can tell, I am not trying to weaken either ST or<br>
STM in any way here.<br>
<br>
I found the STMonadTrans package on Hackage [1] that claims to<br>
implement ST as a monad transformer, STT, which sounds close to what I<br>
want. While its documentation does not mention STM, it does say that<br>
some monads are unsafe to use as a base monad for STT.<br>
<br>
Is STMonadTrans safe to use with STM?<br>
<br>
[1] <a href="https://hackage.haskell.org/package/STMonadTrans" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/STMonadTrans</a><br>
<br>
Thanks,<br>
Thomas Koster<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>