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<derek.a.elk...@gmail.com> wrote: > On Fri, Aug 21, 2009 at 5:04 AM, Lennart > Augustsson<lenn...@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 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<bugf...@gmail.com> 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. > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe