On Fri, Aug 21, 2009 at 5:03 AM, David Menendez d...@zednenem.com wrote:
On Thu, Aug 20, 2009 at 6:57 PM, Peter Verswyvelenbugf...@gmail.com
wrote:
On Thu, Aug 20, 2009 at 11:23 PM, David Menendez d...@zednenem.com
wrote:
The important things to note are (1) getChar# depends on the
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Bulat Ziganshin
To: Peter Verswyvelen
But how does GHC implement the RealWorld internally? I guess
look the base library sources for RealWorld
IO also seems to use unboxed (hence strict?) tuples
newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #))
Not sure if this is just for performance, but if the strictness is required,
here we have the horrible hack again then (would behave different without
it?). I guess it works
Internally GHC does have to enforce the ordering on IO operations somehow.
If there actually was a RealWorld value being passed around you could
use some version of seq the guarantees sequential evaluation.
But GHC doesn't even pass a RealWorld around, the sequencing is
enforced by different
You need a lot of magic to make the IO monad efficient.
You don't really want to pass around (and pattern match on) a
RealWorld token, that would be inefficient.
On Fri, Aug 21, 2009 at 11:04 AM, Peter Verswyvelenbugf...@gmail.com wrote:
IO also seems to use unboxed (hence strict?) tuples
...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Lennart Augustsson
| Sent: 21 August 2009 11:04
| To: Peter Verswyvelen
| Cc: Bayley, Alistair; The Haskell Cafe
| Subject: Re: Re[2]: [Haskell-cafe] Re: Where do I put the seq?
|
| You need a lot of magic to make the IO monad
On Fri, Aug 21, 2009 at 5:04 AM, Lennart
Augustssonlenn...@augustsson.net wrote:
On Fri, Aug 21, 2009 at 10:52 AM, Bayley, Alistair
alistair.bay...@invesco.com wrote:
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Bulat Ziganshin
To: Peter
On Fri, Aug 21, 2009 at 4:37 AM, Peter Verswyvelenbugf...@gmail.com wrote:
On Fri, Aug 21, 2009 at 5:03 AM, David Menendez d...@zednenem.com wrote:
I'm not sure I understand your question, but I think it's possible to
use interact in the way you want. For example, this code behaves
correctly
On Fri, Aug 21, 2009 at 6:53 PM, David Menendez d...@zednenem.com wrote:
You would still need to determine whether you've reached EOF or not,
which forces the input to be determined up to the first line-break or
EOF.
Good point! I actually had it on my TODO list, but that settles it then :)
On Fri, Aug 21, 2009 at 3:29 PM, Peter Verswyvelenbugf...@gmail.com wrote:
On Fri, Aug 21, 2009 at 6:53 PM, David Menendez d...@zednenem.com wrote:
Some people dislike seq because it lets you force strictness
in cases where pattern matching cannot (like function arguments), but
hardly anyone
The question is, in this case when the user gets to see a bit too much of
the output before he sees the input, if that really qualifies as an
incorrect program. It's a bit in the gray zone I guess. You could even
argue that it's a feature that input and output are not really synched, they
are
typo, sees the input = must enter the input
On Fri, Aug 21, 2009 at 10:28 PM, Peter Verswyvelen bugf...@gmail.comwrote:
The question is, in this case when the user gets to see a bit too much of
the output before he sees the input, if that really qualifies as an
incorrect program. It's a bit in
The IO in hbc was (is) the old request-response model, on top of which
there was also a continuation layer, as well as the monadic IO (once
that was invented). It involved a lot more C code handling the
requests than I really liked.
BTW, unsafePerformIO is pretty ugly to implement in the
On Wed, Aug 19, 2009 at 1:20 PM, Peter Verswyvelenbugf...@gmail.com wrote:
Well I really wrote this code as an exercise, and it was a good one. Now I
(or someone) needs to explain why it works.
There's a bit of trickiness, but it's not that hard when you break it down.
Lets look at a
This is very very informative, thanks.
One thing I still struggle with (because I haven't practiced much I guess)
is writing down the desugaring/evaluation/expansion/reduction (how do you
call it?). I know how to do it more or less (tried it for a fix fac, since
fix feels like magic for an
Peter Verswyvelen 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
I don't fully understand.
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?
and since the input that the user gives depends on the output on
It seems that with Ryan's approach, DList is not needed, simple concat works
fine.
It also seems to run in constant space. Now I must do the exercise of
rewriting it to see why concat works, since = is infixl and ++ is infixr,
this seems odd :) But again, my mind might be thinking too strict (bad
On Thu, Aug 20, 2009 at 2:52 AM, Jules Bean ju...@jellybean.co.uk wrote:
Peter Verswyvelen 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.
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
On Thu, Aug 20, 2009 at 7:37 AM, David Leimbachleim...@gmail.com wrote:
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
On Thu, Aug 20, 2009 at 9:56 AM, Ryan Ingramryani.s...@gmail.com wrote:
Compare these identical code fragments:
Er, strike identical. Oops! Comparing identical fragments would be boring.
-- ryan
___
Haskell-Cafe mailing list
Using seq to control a program's semantics (as in, input-output
behaviour) is a horrible hack.
The seq operation there to control space and time aspects of your program.
(The specification of seq doesn't even say that the first argument is
evaluated before the second one.)
You should use data
David Leimbach leim...@gmail.com writes:
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
On Thu, Aug 20, 2009 at 1:02 PM, Ketil Maldeke...@malde.org wrote:
David Leimbach leim...@gmail.com writes:
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,
I totally agree that data dependencies are the best way to do that. And I'm
beginning to see why interact might not be suitable for demonstrating FRP.
On the other hand, when you say data dependencies, you mean that the value
of expression A depends on the value of expression B, but what if that
Peter,
I think you are right that there is no way in general to prevent a valid
graph rewrite to remove a vacuous dependency. That is why seq is there.
The funny business is visible right in the type signature of seq:
seq :: forall a t. a - t - t
If seq had nonstrict semantics, this would
On Thu, Aug 20, 2009 at 3:43 PM, Peter Verswyvelenbugf...@gmail.com wrote:
Also doesn't Haskell's IO system uses a hidden RealWorld type that has no
value but which is passed from between monadics binds in a strict way to
make the ordering work?
Haskell only describes how the IO monad
But how does GHC implement the RealWorld internally? I guess this can't be
done using standard Haskell stuff? It feels to me that if I would implement
it, I would need seq again, or a strict field, or some incrementing time
value that is a strict argument of each of the IO primitives. In any case,
On Thu, Aug 20, 2009 at 4:41 PM, Peter Verswyvelenbugf...@gmail.com wrote:
But how does GHC implement the RealWorld internally? I guess this can't be
done using standard Haskell stuff? It feels to me that if I would implement
it, I would need seq again, or a strict field, or some incrementing
On Thu, Aug 20, 2009 at 11:23 PM, David Menendez d...@zednenem.com wrote:
The important things to note are (1) getChar# depends on the token
returned by putChar#, thus guaranteeing that putChar# gets executed
first, and (2) putChar# and getChar# are impure and cannot normally be
defined in
On Thu, Aug 20, 2009 at 6:57 PM, Peter Verswyvelenbugf...@gmail.com wrote:
On Thu, Aug 20, 2009 at 11:23 PM, David Menendez d...@zednenem.com wrote:
The important things to note are (1) getChar# depends on the token
returned by putChar#, thus guaranteeing that putChar# gets executed
first,
Hello Peter,
Friday, August 21, 2009, 12:41:35 AM, you wrote:
But how does GHC implement the RealWorld internally? I guess
look the base library sources for RealWorld
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
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
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,
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 8:12 AM, Peter Verswyvelen bugf...@gmail.comwrote:
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
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#a8330The 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 =
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 bugf...@gmail.comwrote:
I fixed it myself but it's really tricky :-)
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
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 leim...@gmail.com wrote:
This doesn't seem to be working for me interactively though on a Mac. I
still
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,
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
Have you spoken to Conal Elliott about this stuff? He might be interested.
He was looking for doing this sort of thing on iPhones for a bit.
Also, I was wondering if you thought this Monad might be useful as a way to
automate tasks in an Expect like fashion. I've been struggling with a good
way
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 bugf...@gmail.comwrote:
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 Verswyvelenbugf...@gmail.com wrote:
Expect more bugs with
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 ryani.s...@gmail.com wrote:
I posted a reply to your paste with a stricter version of S
I've corrected it. It still doesn't suffer looping. :-)
On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach leim...@gmail.com wrote:
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
The cleaned up code didn't seem to work for me, it printed everything before
asking input again.
But I added a patch that looks like it supports looping, but I don't
understand exactly what is going on :-)
I added the delay function which makes appending to the output less
strict.
Note that in
Added a new version (tested, works with infinite loops, no early output, etc.)
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8343
I'll put up a short write-up after lunch.
-- ryan
On Wed, Aug 19, 2009 at 11:28 AM, Peter Verswyvelenbugf...@gmail.com wrote:
The cleaned up code didn't
Very cool!
I am still wondering what the significance of the DList is with this though,
or why it was needed to begin with.
Dave
On Wed, Aug 19, 2009 at 12:28 PM, Ryan Ingram ryani.s...@gmail.com wrote:
Added a new version (tested, works with infinite loops, no early output,
etc.)
Wow, very nice cleanup! That's really a good way for me to learn, thanks.
Well, my intuition told me that strings and ++ wouldn't work, since what we
want is an infinite list of output strings, and using ++ would result in
(((s1++s2)++s3)++s4)++s5... which is highly inefficient and I think it
Hmmm very interesting thinking on this. Perhaps ByteStrings would be a good
way to go for efficiency of composition.
I'd love to see some profiling of all of this as part of the lesson at some
point. (Perhaps with vacuum visualization?)
This thread has tackled 3 major tricky issue areas with
Well I really wrote this code as an exercise, and it was a good one. Now I
(or someone) needs to explain why it works.
But is this monad really useful? I mean it would be straightforward to write
this using the ST monad I guess?
Anyway, the reason why I want this pure code is that even with a
53 matches
Mail list logo
