I was very surprised to find "fdRead" returning a String in the ByteString version of the library:
I belatedly found the below thread when trying to figure out what went down with unix-2.5.1.0, and it seems that the impetus for the ".ByteString" modules was to change file path representation, not the representation of file contents.
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 file names.)
-Ryan
On Fri, Nov 11, 2011 at 11:23 AM, Simon Marlow
<marlowsd@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.
Cheers,
Simon
commit d5e43be90d3c6f8869dd2b0c65800c9a6dd0ac70
Author: Simon Marlow <marlowsd@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries