Proposal: add ByteString support to unix:System.Posix.IO API

Simon Marlow marlowsd at
Wed Mar 2 14:49:42 CET 2011

On 28/02/2011 22:57, wren ng thornton wrote:
> On 2/28/11 12:28 PM, Johan Tibell wrote:
>> On Mon, Feb 28, 2011 at 9:20 AM, Bryan O'Sullivan<bos at>
> wrote:
>>> On Sun, Feb 27, 2011 at 9:18 PM, wren ng thornton<wren at>
> wrote:
>>>> I've written variants of the System.Posix.IO API for strict and lazy
>>>> ByteStrings which are currently lingering in their own unpublished
>>>> package[1]. It's silly to have a separate package for just four
> functions,
>>>> so I'd like to see it combined into the unix package. I don't have
> access to
>>>> create a new ticket with the patch, but it's available at [2].
>>> I think that the strict bytestring version should just replace the current
>>> function in System.Posix.IO, and the lazy version should not go in at all.
>>> This is the approach taken by the network package, and it's cleanest.
>> Thanks for working on this Wren.
>> I agree with Bryan's point.
> So then what would become of the string variants? Backwards compatibility
> and all... not _everyone_ uses ByteStrings yet.

The unix package is tied to GHC releases, where the usual convention is 
to DEPRECATE for one major release (~ 12 months), then remove in the 
next release.


> Also, FWIW, the real impetus behind writing these was to deal with lazy
> ByteStrings, since that's what one of my dependencies uses[1]. It seems
> like a common enough situation that it should be handled directly. Forcing
> people to call (BS.concat . BL.toChunks) first muddies up the code and
> introduces additional copying, whereas making people use (mapM_ fdWrite .
> BL.toChunks) is still rather messy and it's buggy in the face of partial
> writes.
> For network usage I agree that the strict-only approach is clean and
> effective. For general purpose writing to Fds, I'm not so sure.
> [1]

More information about the Libraries mailing list