'OutputStream Builder' has confusing semantics

[23Skidoo]

Consider the following program:

{-# LANGUAGE OverloadedStrings #-}
module Test where

import qualified System.IO.Streams as Streams
import qualified Blaze.ByteString.Builder as Builder

example0 = do os <- Streams.builderStream Streams.stdout
              Streams.write (Just $ Builder.fromByteString "Hello, world!\n") os
              Streams.write (Just $ Builder.fromByteString "Bye, world!\n") os
              Streams.write Nothing os

example1 = do os  <- Streams.builderStream Streams.stdout
              is0 <- Streams.fromByteString "Hello, world!\n" >>= Streams.map Builder.fromByteString
              is1 <- Streams.fromByteString "Bye, world!\n"   >>= Streams.map Builder.fromByteString
              Streams.connect is0 os
              Streams.connect is1 os
              Streams.write Nothing os

Just looking at the code, I'd expect the output in both cases to be identical. In the first case I get the expected result:

ghci> example0
Hello, world!
Bye, world!

However, in the second case I get:

ghci> example1
Hello, world!
Hello, world!
Bye, world!
Hello, world!
Bye, world!

The result also depends on the position of the Streams.write Nothing os line. E.g. if I delete it, I get:

ghci> example1
Hello, world!
Hello, world!
Bye, world!

And if I move it before the last connect, I get:

ghci> example1
Hello, world!
Hello, world!
Hello, world!
Bye, world!

All this is utterly confusing.

[gregorycollins]

The bug here is that after the first connect, subsequent writes to the channel should be no-ops (i.e. the output stream should be closed because connect sends EOF). It looks like instead we're retaining part of the buffer.

[gregorycollins]

Hm, weird, I can't reproduce with "listOutputStream". Maybe the problem is in the handle code.

[gregorycollins]

The default stuff that comes out of the box should be safe, i.e. we should have enforced the stream invariant for you with "makeOutputStream". Should be fixed now.

[23Skidoo]

The bug here is that after the first connect, subsequent writes to the channel should be no-ops (i.e. the output stream should be closed because connect sends EOF).

Thanks, makes sense.