
I was very surprised to find "fdRead" returning a String in the ByteString
version of the library:
http://hackage.haskell.org/packages/archive/unix/2.5.1.0/doc/html/System-Pos...
Unlike, for example the fdRead in unix-bytestring:
http://hackage.haskell.org/packages/archive/unix-bytestring/0.3.5/doc/html/S...
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
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 d5e43be90d3c6f8869dd2b0c65800c**9a6dd0ac70 Author: Simon Marlow
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