Proposal: add ByteString support to unix:System.Posix.IO API
marlowsd at gmail.com
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 serpentine.com>
>>> On Sun, Feb 27, 2011 at 9:18 PM, wren ng thornton<wren at freegeek.org>
>>>> I've written variants of the System.Posix.IO API for strict and lazy
>>>> ByteStrings which are currently lingering in their own unpublished
>>>> package. It's silly to have a separate package for just four
>>>> 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 .
>>> 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
> Also, FWIW, the real impetus behind writing these was to deal with lazy
> ByteStrings, since that's what one of my dependencies uses. 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
> 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.
More information about the Libraries