Library/IO
From HaskellWiki
| Line 1: | Line 1: | ||
[[Category:Libraries]] | [[Category:Libraries]] | ||
| - | This page describes my proposal for development of new standard low-level I/O library [[User:Bulatz|Bulatz]] 09:29, 13 March 2007 (UTC) | + | This page describes my proposal for development of new standard low-level I/O library -- [[User:Bulatz|Bulatz]] 09:29, 13 March 2007 (UTC) |
| - | The existing GHC I/O library (based on using Handles) is very feature-rich, but it cannot be extended any more. The reason is that this library has non-modular design where all features are closely coupled with each other and GHC RTS. But we need to further extend it, adding the | + | The existing GHC I/O library (based on using Handles) is very feature-rich, but it cannot be extended any more. The reason is that this library has non-modular design where all features are closely coupled with each other and GHC RTS. But we need to further extend it, adding the following facilities: |
* More models for async i/o (support for kqueue,epoll,AIO) | * More models for async i/o (support for kqueue,epoll,AIO) | ||
* Unicode filenames on windows and unix | * Unicode filenames on windows and unix | ||
* Using ByteString/UTF8String/UTF16String for filenames | * Using ByteString/UTF8String/UTF16String for filenames | ||
| + | * Various encodings (UTF8,UTF16...) for text files | ||
* Files>4gb on windows | * Files>4gb on windows | ||
* Memory-mapped files | * Memory-mapped files | ||
* ByteString i/o | * ByteString i/o | ||
* Binary i/o and binary serialization | * Binary i/o and binary serialization | ||
| + | |||
| + | Although additional libraries ([1]-[4]) solves almost every problem mentioned here, they are not coupled together - you can't use async i/o from network-alt with ByteString I/O from FPS and Char encoding routines from Streams. I don't even say that most of this features are simply not available for other Haskell compilers. | ||
| + | |||
| + | On the other hand, there are alternative designs for implementation of higher-level features such as buffering and text encoding (at least, Streams vs SSC). Moreover, higher-level implementation greaty depends on language-extension features (such as MPTC+FD) whose support varies between haskell compilers. As a result, i propose to develop standard *low-level* I/O library that | ||
Revision as of 09:39, 13 March 2007
This page describes my proposal for development of new standard low-level I/O library -- Bulatz 09:29, 13 March 2007 (UTC)
The existing GHC I/O library (based on using Handles) is very feature-rich, but it cannot be extended any more. The reason is that this library has non-modular design where all features are closely coupled with each other and GHC RTS. But we need to further extend it, adding the following facilities:
- More models for async i/o (support for kqueue,epoll,AIO)
- Unicode filenames on windows and unix
- Using ByteString/UTF8String/UTF16String for filenames
- Various encodings (UTF8,UTF16...) for text files
- Files>4gb on windows
- Memory-mapped files
- ByteString i/o
- Binary i/o and binary serialization
Although additional libraries ([1]-[4]) solves almost every problem mentioned here, they are not coupled together - you can't use async i/o from network-alt with ByteString I/O from FPS and Char encoding routines from Streams. I don't even say that most of this features are simply not available for other Haskell compilers.
On the other hand, there are alternative designs for implementation of higher-level features such as buffering and text encoding (at least, Streams vs SSC). Moreover, higher-level implementation greaty depends on language-extension features (such as MPTC+FD) whose support varies between haskell compilers. As a result, i propose to develop standard *low-level* I/O library that
