Wait... System.Posix.IO.ByteString reads data into a *String*?
rrnewton at gmail.com
Mon Feb 20 06:39:14 CET 2012
I was very surprised to find "fdRead" returning a String in the ByteString
version of the library:
Unlike, for example the fdRead in unix-bytestring:
I belatedly found the below thread when trying to figure out what went down
with unix-18.104.22.168, and it seems that the impetus for the ".ByteString"
modules was to change file path representation, not the representation of
But I'm missing why this would be. If it is a distinct module namespace,
why would there be any backwards compatibility concerns? And if taking
this one step towards ByteString why not go all the way? (Especially as
file contents are much larger and therefore more performance critical than
On Fri, Nov 11, 2011 at 11:23 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> I propose to commit the attached patch to the unix package and release it
> with GHC 7.4.1. The commit log is reproduced below. Comments please!
> The unix version number will of course be bumped appropriately.
> commit d5e43be90d3c6f8869dd2b0c65800c**9a6dd0ac70
> Author: Simon Marlow <marlowsd at gmail.com>
> Date: Fri Nov 11 16:18:48 2011 +0000
> Provide a raw ByteString version of FilePath and environment APIs
> The new module System.Posix.ByteString provides exactly the same API
> as System.Posix, except that:
> - There is a new type: RawFilePath = ByteString
> - All functions mentioning FilePath in the System.Posix API
> use RawFilePath in the System.Posix.ByteString API
> - RawFilePaths are not subject to Unicode locale encoding and
> decoding, unlike FilePaths. They are the exact bytes passed to
> and returned from the underlying POSIX API.
> - Similarly for functions that deal in environment
> strings (System.Posix.Env): these use untranslated ByteStrings
> in System.Posix.Environment
> - There is a new function
> System.Posix.ByteString.**getArgs :: [ByteString]
> returning the raw untranslated arguments as passed to exec()
> when the program was started.
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries