What Functions are Standard?
Hello, I have been writing code using the docs over at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html, which is the only comprehensive library reference I could find. I am using some code from System.IO, supposedly from base. When I try to build this with nhc98, it doesn't know about hGetBuf, hPutBuf, or openBinaryFile from there or about mallocForeignPtrArray from the Foreign.* area. But all these look standard to me. What am I missing here? Does nhc98 really completely lack the ability to read binary data from a file? Or where should I be finding it, and how could I have known for myself that those particular ghc functions were unsupported elsewhere? -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715
John Goerzen wrote:
Hello,
I have been writing code using the docs over at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html, which is the only comprehensive library reference I could find.
I am using some code from System.IO, supposedly from base. When I try to build this with nhc98, it doesn't know about hGetBuf, hPutBuf, or openBinaryFile from there or about mallocForeignPtrArray from the Foreign.* area. But all these look standard to me.
They aren't; they are GHC extensions, except for mallocForeignPtrArray, which is specified by the FFI addendum: http://www.cse.unsw.edu.au/~chak/haskell/ffi/
What am I missing here? Does nhc98 really completely lack the ability to read binary data from a file?
I can't comment on nhc98, but the Haskell98 standard doesn't include any mechanism for binary I/O.
Or where should I be finding it, and how could I have known for myself that those particular ghc functions were unsupported elsewhere?
The Haskell98 report can be found at: http://www.haskell.org/onlinereport/ Anything which isn't listed there is essentially a vendor extension. -- Glynn Clements <glynn.clements@virgin.net>
John Goerzen <jgoerzen@complete.org> writes:
On 2004-10-06, Glynn Clements <glynn.clements@virgin.net> wrote:
I can't comment on nhc98, but the Haskell98 standard doesn't include any mechanism for binary I/O.
Ouch. That seems like a major oversight to me. Will there be any effort to fix that in the future?
Note that, on Unix-like systems, there is no difference between text I/O and binary I/O on files. It is only Windows that requires a separation of the modes. As to fixing the Haskell standard - well, the base hierarchical libraries are a de facto "corrected" set of libraries. It is just that not all compilers have yet caught up with them. Regards, Malcolm
Malcolm Wallace wrote:
I can't comment on nhc98, but the Haskell98 standard doesn't include any mechanism for binary I/O.
Ouch. That seems like a major oversight to me. Will there be any effort to fix that in the future?
Note that, on Unix-like systems, there is no difference between text I/O and binary I/O on files. It is only Windows that requires a separation of the modes.
There are two issues here. The first is EOL conversion; as Malcom notes, this isn't an issue on Unix, but it is an issue on Windows. On Windows, there is no standard way to obtain the contents of a file such that \n and \r\n are distinct. The second is character encoding/decoding. The Haskell98 I/O functions all deal with Chars. When reading a file, the byte stream is converted to a list of characters using an *unspecified* encoding. AFAIK, all implementations are currently hardcoded to assume ISO-8859-1, so you can reliably obtain the original list of bytes using the ord function. However, nothing in the standard dictates that ISO-8859-1 is used, and there has been talk of using the locale's encoding instead. If that were to happen, it would be practically (as well as theoretically) impossible to perform binary I/O using the Haskell98 API, even on Unix. This issue has been beaten to death fairly recently, so I'm not going to repeat it here. See the thread entitled "Writing binary files" from Sep 11-18 for the details. -- Glynn Clements <glynn.clements@virgin.net>
participants (3)
-
Glynn Clements -
John Goerzen -
Malcolm Wallace