Re: Re[2]: [Haskell-cafe] Re: Where do I put the seq?

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 request-response model. I take that as a sign that unsafePerformIO is bad. :) -- Lennart On Fri, Aug 21, 2009 at 3:14 PM, Derek Elkins wrote:

On Fri, Aug 21, 2009 at 5:04 AM, Lennart Augustsson wrote:

...

...

On Fri, Aug 21, 2009 at 10:52 AM, Bayley, Alistair wrote:

...

...

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@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"

http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IOBas e.html#IO

On Fri, Aug 21, 2009 at 11:04 AM, Peter Verswyvelen wrote: 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 because when applying primitive function likes putChar#, these could be considered as fully strict, since putChar# c really does force evaluation of c strictly and puts in the screen. This is different from the lazy IO situation, where a string is concatenated lazily, and put on the screen by the consumer as soon as it's available. Ah I'm having troubles to explain myself formally, never mind :) Actually RealWorld is not defined in that file, it is defined here, but hidden file:///C:/app/ghp/doc/libraries/ghc-prim/GHC-Prim.html#t%3ARealWorld But I don't understand the comment data RealWorld Source RealWorld is deeply magical. It is primitive, but it is not unlifted (hence ptrArg). We never manipulate values of type RealWorld; it's only used in the type system, to parameterise State#. Maybe I should reread the papers, but it seems lots of magic is needed to get IO right (such as the existential types to make sure different state threads are kept separate)

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.

I've always preferred the continuation based implementation of IO as used in Hugs and I believe in HBC.  GHC's handling of it has always seemed hack-y to me.  I don't recall any special treatment of IO by HBC, though Lennart will definitely be able to verify or deny that.