<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">From: Magnus Therning &lt;<a href="mailto:magnus@therning.org">magnus@therning.org</a>&gt;<br>

<br>
On 24/08/10 03:47, John Millikin wrote:<br>
[...]<br>
&gt; I would like to avoid hard-coding the error type to SomeException, because<br>
&gt; it forces libraries to use unsafe/unportable language features (dynamic<br>
&gt; typing and casting). However, given the apparent practical requirement that<br>
&gt; all iteratees have the same error type, it seems like there&#39;s no other<br>
&gt; choice.<br>
<br>
I haven&#39;t worked enough with iteratees to have an informed opinion on this,<br>
but I wonder what the pros and cons are of having an error state in the<br>
iteratees at all.  In other words, why would this<br>
<br>
  data Step a m b<br>
      = Continue (Stream a -&gt; Iteratee a m b)<br>
      | Yield b (Stream a)<br>
      | Error E.SomeException<br>
<br>
be preferred over this<br>
<br>
  data Step a m b<br>
      = Continue (Stream a -&gt; Iteratee a m b)<br>
      | Yield b (Stream a)<br>
<br>
(Maybe with the restriction that m is a MonadError.)<br></blockquote><div><br></div><div>Oleg included the error state to enable short-circuiting of computation, and I guess everyone just left it in.  Recently I&#39;ve been wondering if it should be removed, though, in favor requiring explicit (i.e. explicit in the type sig) exceptions for everything.  I&#39;m not sure if that would be more or less complicated.</div>
<div><br></div><div>John</div></div>