It doesn&#39;t work like that by default, and here is why:<br><br>-- an infinite tree of values<br>data InfTree a = Branch a (InfTree a) (InfTree a)<br><br>buildTree :: Num a =&gt; STRef s a -&gt; ST s (InfTree a)<br>buildTree ref = do<br>
    n &lt;- readSTRef ref<br>    writeSTRef ref $! (n+1)<br>    left &lt;- buildTree ref<br>    right &lt;- buildTree ref<br>    return (Branch n left right)<br><br>makeTree :: Num a =&gt; ST s (InfTree a)<br>makeTree = do<br>
    ref &lt;- newSTRef 0<br>    buildTree ref<br><br>-- should be referentially transparent, i.e. these two expressions should be equivalent<br>pureInfTree1, pureInfTree2 :: InfTree Integer<br>pureInfTree1 = runST makeTree<br>
pureInfTree2 = runST makeTree<br><br>element (Branch x _ _) = x<br>goLeft (Branch _ x _) = x<br>goRight (Branch _ _ x) = x<br><br>test :: IO ()<br>test = do<br>   let left1 = goLeft pureInfTree1<br>   let right1 = goRight pureInfTree1<br>
   let left2 = goLeft pureInfTree2<br>   let right2 = goRight pureInfTree2<br>
   evaluate (element left1)<br>   evaluate (element right1)<br>   evaluate (element right2)<br>   evaluate (element left2)<br>   print (element left1 == element left2)  -- should be True!<br><br>Right now this code diverges, because buildTree diverges.  If buildTree was lazy, test would print False because of the order of evaluation.  You can make buildTree lazy if you want:<br>
<br>import Control.Monad.ST.Unsafe<br><br>buildTree :: Num a =&gt; STRef s a -&gt; ST s (InfTree a)<br>
buildTree ref = do<br>
    n &lt;- readSTRef ref<br>
    writeSTRef ref $! (n+1)<br>
    left &lt;- unsafeInterleaveST (buildTree ref)<br>
    right &lt;- unsafeInterleaveST (buildTree ref)<br>
    return (Branch n left right)<br>
<br>In order to safely use unsafeInterleaveST, you need to prove that none of the references used by the computation passed to unsafeInterleaveST can be used by any code after the unsafeInterleaveST; so this &#39;lazy&#39; list generation is safe:<br>
<br>buildList :: Num a =&gt; STRef s a -&gt; ST s [a]<br>buildList = do<br>    ref &lt;- newSTRef 0<br>    let loop =<br>        n &lt;- readSTRef ref<br>        writeSTRef ref $! (n+1)<br>        rest &lt;- unsafeInterleaveST loop<br>
        return (n : rest)<br>    loop<br><br>because we are guaranteed that the only reference to ref exists inside the loop which uses it in a linear fashion.  So you may be able to get away with it... but you have to make a proof manually that the compiler isn&#39;t able to infer for you.<br>
<br>  -- ryan<br><br><br><div class="gmail_quote">On Sun, Jun 10, 2012 at 5:37 AM, Nicu Ionita <span dir="ltr">&lt;<a href="mailto:nicu.ionita@acons.at" target="_blank">nicu.ionita@acons.at</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I&#39;m trying to produce a list in the strict ST monad. The documentation  of ST says that the monad is strict in the state, but not in the values. So I expect that, when returning a list, I get back only the Cons (with 2 unevaluated thunks). Now, when I need the first element (head), this will be evaluated (with whatever actions are necessary in the ST universe) and the tail is again a Cons with unevaluated parts.<br>

<br>
Internally my list is stored in a vector, and the elements are generated phasewise, each phase generating 0 or more elements in the vector, and a fuction splitMove is driving this process (see code below). I would expect that the first phase triggers, generates some moves, then (after these are consumed from the list) the next phase triggers generating the next few moves and so on.<br>

<br>
But when I trace the phases (Debug.Trace.trace) I get all the trace messages in front of the first move:<br>
<br>
Moves for fen: rnbqkbnr/pp3ppp/4p3/2pp4/3P4/<u></u>2NQ4/PPP1PPPP/R1B1KBNR w<br>
After move generation...<br>
0 &gt;= 0 : next phase<br>
3 &gt;= 3 : next phase<br>
3 &gt;= 3 : next phase<br>
42 &gt;= 42 : next phase<br>
44 &gt;= 44 : next phase<br>
d4c5<br>
g1f3<br>
g1h3<br>
c3b1<br>
...<br>
<br>
This seems not to be just an unhappy combination between trace and ST, as also the program without trace is beeing slower than the same implemented with plain lists, which is hard to believe (in many cases the move list is not consumed to the end).<br>

<br>
I wonder if my expectation is wrong, but I don&#39;t find a way to do this. Here is the (incomplete) code:<br>
<br>
produceList ... = runST $ do<br>
    ml &lt;- newMList ...<br>
    listMoves ml<br>
<br>
-- Transforms a move list to a list of moves - lazy<br>
listMoves :: MList s -&gt; ST s [Move]<br>
listMoves ml = do<br>
    sm &lt;- splitMove ml<br>
    case sm of<br>
        Just (m, ml&#39;) -&gt; do<br>
            rest &lt;- listMoves ml&#39;<br>
            return $ m : rest<br>
        Nothing       -&gt; return []<br>
<br>
-- Split the first move from the move list and return it together with<br>
-- the new move list (without the first move). Return Nothing if there<br>
-- is no further move<br>
splitMove :: MList s -&gt; ST s (Maybe (Move, MList s))<br>
splitMove ml<br>
    | mlToMove ml &gt;= mlToGen ml = do<br>
        mml &lt;- trace trm $ nextPhase ml<br>
        case mml of<br>
            Nothing  -&gt; return Nothing<br>
            Just ml&#39; -&gt; splitMove ml&#39;<br>
    | otherwise = do<br>
        m &lt;- U.unsafeRead (mlVec ml) (mlToMove ml)<br>
        case mlCheck ml ml m of<br>
            Ok    -&gt; return $ Just (m, ml1)<br>
            Skip  -&gt; splitMove ml1<br>
            Delay -&gt; splitMove ml1 { mlBads = m : mlBads ml }<br>
    where ml1 = ml { mlToMove = mlToMove ml + 1 }<br>
          trm  = show (mlToMove ml) ++ &quot; &gt;= &quot; ++ show (mlToGen ml) ++ &quot; : next phase&quot;<br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br>