Doesn't seem to compile. I nearly never use case statements in my code, so I'm not really sure what's going on.
neat2.hs:14:39: parse error on input `=' Dave On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram <[email protected]> wrote: > I posted a reply to your paste with a stricter version of S and some > cleanup. > > Untested, though I believe it should work without "seq". > > "case" provides all the strictness you need, I think! > > -- ryan > > 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 from 1986, converted by myself in C++ to > >> PocketPC as G-Pod, 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 > >>>>>>> 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 > > > > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
