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

[Lennart Augustsson]

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.elkins at gmail.com> wrote:
> 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.
>