I don't fully understand.<div><br></div><div>interact gives you a stream of input characters that the user types, and produces a stream of output characters that are displayed back (with buffering set to NoBuffering). it should behave predictable no? </div>
<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 also remember from the Haskell School of Expression that putting lazy pattern matches (in switch if I recall correctly) here and there is needed to avoid blocking or inf loops. Also in Reactive this was important. In Yampa you need to mark the outputs strict to avoid delayed computations from building up (like sum and foldl does). So it seems finding a good balance between strictness and laziness is really important in FRP, at least for the engine, and in the case of Yampa, also for the end user.</div>
<div><br></div><div>E.g in Ryans cleanup, if you replace inp by</div><div><br></div><div><div>inp :: S String</div><div>inp = S $ \i -> (tail i, D.empty, head i)</div><div><br></div><div>then the ordering of input to output is incorrect, too much output is printed before the input is requested. it clearly demonstrates the effect of laziness to me really, in a much easier to observe way than stack overflows or infinite loops no?</div>
<div><br></div></div><div>how is interact different from a graphical user interface system or game simulation, in which the input is a stream of events (or behaviors, samples, whatever) from mouse, keyboard, timers, etc, and the output is a list of pictures or geometry? </div>
<div><br></div><div>The tutorial I would like to make is exactly for this kind of feedback from domain experts, so maybe "tutorial" is not the correct word, more a discussion or journey. </div><div><br></div><div>
Anyway I don't think I'm qualified to make a tutorial since I'm still learning the basics, but with feedback from you guys (I already have interest from <span class="Apple-style-span" style="border-collapse: collapse; white-space: pre-wrap; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; ">Hai (Paul) Liu (Yampa) and Patai Gergely (Elerea) it might still become a valuable resource?</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; white-space: pre-wrap; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;"><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">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>