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

[Derek Elkins]

On Fri, Aug 21, 2009 at 5:04 AM, Lennart
Augustsson<lennart at augustsson.net> wrote:
>> On Fri, Aug 21, 2009 at 10:52 AM, Bayley, Alistair
>> <Alistair.Bayley at invesco.com> wrote:
>>>
>>> > From: haskell-cafe-bounces at haskell.org
>>> > [mailto:haskell-cafe-bounces at 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<bugfact at 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.