 <p>Using the list monad would let you structure the computation like a tree, but it would lose the source information. At the end, you would have a list of results, but you would not know where each individual result came from.</p> <p>If this is all you care about, the list monad is perfect. Let's imagine you have a non-deterministic <code>step</code> function:</p> <pre><code>step :: State -&gt; [State] </code></pre> <p>if we want to just step it through a bunch of times, we could write something like:</p> <pre><code>startState &gt;&gt;= step &gt;&gt;= step &gt;&gt;= step </code></pre> <p>this will give us all the possible results after 3 steps. If we wanted to generalize this to any number, we could write a simple helper function by using the monadic composition operator <code>(&lt;=&lt;)</code> from <code>Control.Monad</code>. This works just like <code>.</code>, except for function of the form <code>a -&gt; m b</code> instead of normal functions (<code>a -&gt; b</code>). It could look something like this:</p> <pre><code>stepN :: Int -&gt; (State -&gt; [State]) -&gt; State -&gt; [State] stepN n f = foldr (&lt;=&lt;) return (replicate n f) </code></pre> <p>Now to get three non-deterministic steps, we can just write <code>stepN 3 step</code>. (You'll probably want to come up with better names for the functions :P.)</p> <p>In summary: using the list monad, the computation <em>itself</em> is shaped like a tree, but you only get to look at the results at the end. This should be clear from the types involved: at the end, you get a <code>[State]</code>, which is by its very nature flat. However, the function <code>State -&gt; [State]</code> branches, so the computation to arrive to the end has to look like a tree.</p> <p>For things like that, the list type is very convenient to use.</p>