<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>