<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><div>and since the input that the user gives depends on the output on the screen (it represents the user <-> machine dialog loop), we must make sure that laziness does not go wild and strictness is needed to respect this dependency. But as Ryan showed, seq is not really needed (but pattern matching is), and his code is super elegant and simple. I </div>
<div></div></blockquote><div> </div><div>I'm pretty certain that forcing a pattern match via case is what disallows the laziness to get out of hand. The case statement, when evaluated, must choose a matched pattern branch, even if it's the only possibility, which ends up boiling down to "seq" anyway doesn't it?</div>
<div><br></div><div>Or is it that case doesn't have to go through as deep an evaluation as seq does in some cases? Does that even make any sense? :-)</div><div><br></div><div>Dave</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><span style="border-collapse:collapse;white-space:pre-wrap"></span></div><div><div></div><div class="h5">
<div><span style="border-collapse:collapse;white-space:pre-wrap"><br></span></div><div><div class="gmail_quote">On Thu, Aug 20, 2009 at 11:52 AM, Jules Bean <span dir="ltr"><<a href="mailto:jules@jellybean.co.uk" target="_blank">jules@jellybean.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter Verswyvelen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not at all, use it for whatever you want to :-)<br>
<br>
I'm writing this code because I'm preparing to write a bunch of tutorials on FRP, and I first wanted to start with simple console based FRP, e.g. making a little text adventure game, where the input/choices of the user might be parsed ala parsec, using monadic style, applicative style, and arrows, and then doing the same with FRP frameworks like <br>
</blockquote>
<br>
<br>
This is a really bad place to start a FRP tutorial IMO.<br>
<br>
The interface for 'interact' does not make any promises about the relative evaluation order of the input list / production order of the output list.<br>
<br>
That's why you are having to play horrible tricks with seq to try to force the order to be what you want.<br>
<br>
I don't think this is the basis of a robust system or a sensible tutorial.<br>
<br>
Just my 2c.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br>