Yet this does work interact $ run test9 test9 = replicateM 9 test
Will run test 9 times. I suppose if one constructed an infinite list you could loop as you wanted to. Yet, that might not be what you want. Dave On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen <[email protected]>wrote: > Expect more bugs with this though :-) Just found out that looping does not > work, it hangs, e.g. > > test = do out "Enter your first name:" fstName <- inp out "Enter your > second name:" sndName <- inp out ("Welcome "++fstName++" "++sndName) out > "Goodbye!"* **test* > > Doesn't seem to work :-) Back to the drawing board. > > > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen <[email protected]>wrote: > >> Not at all, use it for whatever you want to :-) >> 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 Yampa, Elera, >> Reactive, etc... >> >> After that I would start writing tutorials that use OpenGL, making some >> very simple games, again with the above approaches, and ending with a >> conversion of a very old game of mine (Zarathrusta written in assembler from >> 1991, which was based on >> Thrust<http://www.bytecellar.com/archives/000106.php>from 1986, converted by >> myself in C++ to PocketPC as >> G-Pod<http://www.handango.com/catalog/ProductDetails.jsp?productId=16574&platformId=30>, >> and so I would like to make a version in Haskell that runs on the iPhone :-) >> >> This of course is a lot of work, and I would like to put this on the >> Haskell wiki or a blog or something, so others can contribute and comment. I >> would like to show real examples that explain the shortcomings of the FRP >> approaches, because now this is still a bit blurry to me. >> >> >> >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach <[email protected]>wrote: >> >>> This Monad you've created is quite excellent. I was trying to do >>> something like this about a year ago, to make the input and output handling >>> of an interactive bowling score card work nicely. I kept running into >>> issues, and did not believe that seq was going to do the trick. Nice work! >>> This is a very useful monad I think, it could be called "Prompter" or >>> something to that effect. >>> >>> Do you mind if I use it in some of my code? >>> >>> Dave >>> >>> >>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen <[email protected]>wrote: >>> >>>> LOL. Maybe we should have that coffee together ;-) at least virtually! >>>> >>>> On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach <[email protected]>wrote: >>>> >>>>> Argh... I too have been up too late :-). I edited THE WRONG FILE! No >>>>> wonder your change didn't take effect! :-/ >>>>> Time for coffee I suppose. >>>>> >>>>> >>>>> On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach <[email protected]>wrote: >>>>> >>>>>> This doesn't seem to be working for me interactively though on a Mac. >>>>>> I still get "Welcome" before I've entered text. >>>>>> >>>>>> >>>>>> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> I fixed it myself but it's really tricky :-) >>>>>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330 >>>>>>> >>>>>>> <http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330>The idea >>>>>>> is, that when the input is requested, the output that is then generated >>>>>>> must >>>>>>> be in sync with the input. >>>>>>> >>>>>>> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** >>>>>>> **`**seq**`** **D**.**empty**)*, head i) in (tail i, r) >>>>>>> >>>>>>> >>>>>>> >>>>>>> I first had >>>>>>> >>>>>>> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r) >>>>>>> >>>>>>> >>>>>>> But that was too eager, since i syncs the input not with the output, >>>>>>> but with the function that will generate the output. >>>>>>> >>>>>>> Okay, now I can sleep again :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Thanks, but that doesn't really matter in my example, my code is >>>>>>>> just buggy, and I'm not sure why. For example if I change my test >>>>>>>> function >>>>>>>> so that it outputs lines only, then it still prints Welcome first >>>>>>>> before >>>>>>>> asking for input. >>>>>>>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328 >>>>>>>> >>>>>>>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Try LineBuffering. >>>>>>>>> I do linewise stuff with interact a lot. You'll find stuff like >>>>>>>>> >>>>>>>>> unlines . lines >>>>>>>>> >>>>>>>>> may help too. In fact I just wrote a blog post about this. >>>>>>>>> >>>>>>>>> http://leimy9.blogspot.com >>>>>>>>> >>>>>>>>> I'm trying to write some interactive code to automate working with >>>>>>>>> serial console controlled power strips, so I need to either use Expect >>>>>>>>> (yuck) or do my own thing. >>>>>>>>> >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Apparently this particular example happens to work on Mac and >>>>>>>>>> Linux because of different buffering (thanks Martijn for the help!) >>>>>>>>>> To make sure we have no buffering at all, the main function should >>>>>>>>>> be: >>>>>>>>>> >>>>>>>>>> main = do hSetBuffering stdout NoBuffering hSetBuffering stdin >>>>>>>>>> NoBuffering test >>>>>>>>>> >>>>>>>>>> Now I think it should also be *incorrect* on Unix systems. >>>>>>>>>> >>>>>>>>>> I guess the way I'm concatenating the strings is not correct, not >>>>>>>>>> sure. >>>>>>>>>> >>>>>>>>>> I would like to use a graphical tool to show the graph reduction >>>>>>>>>> step by step, to get a better understanding of the laziness & >>>>>>>>>> strictness. >>>>>>>>>> Does such a tool exist? I know people often say this is not usable >>>>>>>>>> because >>>>>>>>>> the amount of information is too much, but I used to be an assembly >>>>>>>>>> language >>>>>>>>>> programmer so I still would like to give it a try :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> In an attempt to get a deeper understanding of several monads >>>>>>>>>>> (State, ST, IO, ...) I skimmed over some of the research papers >>>>>>>>>>> (but didn't >>>>>>>>>>> understand all of it, I lack the required education) and decided to >>>>>>>>>>> write a >>>>>>>>>>> little program myself without using any prefab monad instances that >>>>>>>>>>> should >>>>>>>>>>> mimic the following: >>>>>>>>>>> main = do >>>>>>>>>>> putStrLn "Enter your name:" >>>>>>>>>>> x <- getLine >>>>>>>>>>> putStr "Welcome " >>>>>>>>>>> putStrLn x >>>>>>>>>>> putStrLn "Goodbye!" >>>>>>>>>>> >>>>>>>>>>> But instead of using IO, I wanted to make my own pure monad that >>>>>>>>>>> gets evaluated with interact, and does the same. >>>>>>>>>>> >>>>>>>>>>> However, I get the following output: >>>>>>>>>>> >>>>>>>>>>> Enter your name: >>>>>>>>>>> Welcome ...... >>>>>>>>>>> >>>>>>>>>>> So the Welcome is printed too soon. >>>>>>>>>>> >>>>>>>>>>> This is obvious since my monad is lazy, so I tried to put a seq >>>>>>>>>>> at some strategic places to get the same behavior as IO. But I >>>>>>>>>>> completely >>>>>>>>>>> failed doing so, either the program doesn't print anything and asks >>>>>>>>>>> input >>>>>>>>>>> first, or it still prints too much output. >>>>>>>>>>> >>>>>>>>>>> Of course I could just use ST, State, transformers, etc, but this >>>>>>>>>>> is purely an exercise I'm doing. >>>>>>>>>>> >>>>>>>>>>> So, I could re-read all papers and look in detail at all the >>>>>>>>>>> code, but maybe someone could help me out where to put the seq or >>>>>>>>>>> what to do >>>>>>>>>>> :-) >>>>>>>>>>> >>>>>>>>>>> The code is at >>>>>>>>>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316 >>>>>>>>>>> >>>>>>>>>>> Oh btw, the usage of DList here might not be needed; intuitively >>>>>>>>>>> it felt like the correct thing to do, but when it comes to Haskell, >>>>>>>>>>> my >>>>>>>>>>> intuition is usually wrong ;-) >>>>>>>>>>> >>>>>>>>>>> Thanks a lot, >>>>>>>>>>> Peter Verswyvelen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Haskell-Cafe mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
