
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>Thinking more about this I/O demand analysis thing. I don't think it's possible for the compiler to decide for itself what to fuzz, but a user might know very well. Given</div><div><br></div><div>m >>= f</div><div><br></div><div>there are really two sensible approaches:</div><div><br></div><div>1. Want to ensure m is executed even if the action produced by f will diverge.</div><div><br></div><div>2. Not care whether m is executed if the compound action will ultimately diverge.</div><div><br></div><div>Our current I/O hack mixes these two in an unprincipled way.</div><div><br></div><div>The second approach, not caring, is certainly the most natural for GHC's implementation of I/O: we're defining a function from the real world to a new real world and a value; the function is partial and we don't care about the details. This is fairly clearly the right way to handle strict ST: if we don't get a result at the end, we don't get anything useful and don't care what actions get dropped.</div><div><br></div><div>The first approach seems to offer a better way to explain I/O and evaluation to users, ensuring that evaluation is only performed to the extent necessary for execution. This is partially supported by the I/O hack when it triggers. But it doesn't always, and it's not entirely clear if we can make do so.</div><div><br></div><div>Still no real conclusions here; just exploring the problem more.</div><div><br></div><div id="composer_signature"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><div style="font-size:85%;color:#575757">David Feuer</div><div style="font-size:85%;color:#575757">Well-Typed, LLP</div></div></body></html>