Personal tools

Library/IO

From HaskellWiki

< Library(Difference between revisions)
Jump to: navigation, search
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 following facilities:
 
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:
Line 15: Line 16:
 
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.
 
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
+
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 will hide details of interacion with OS but don't provide any higher-level interfaces to work with files - it would be a business for other libs.
  +
  +
So, what i propose to include in this lib:
  +
  +
0) Prerequisites: implementation in FPS or some other library common operations on ByteString/UTF8String/UTF16String and providing some Stringable class that provides type-independent interface to these operations:
  +
  +
<haskell>
  +
class Stringable a where
  +
length :: a -> Int
  +
concat :: [a] -> a
  +
....
  +
  +
instance Stringable String
  +
instance Stringable ByteString
  +
instance Stringable UTF8String
  +
instance Stringable UTF16String
  +
</haskell>

Revision as of 09:47, 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 will hide details of interacion with OS but don't provide any higher-level interfaces to work with files - it would be a business for other libs.

So, what i propose to include in this lib:

0) Prerequisites: implementation in FPS or some other library common operations on ByteString/UTF8String/UTF16String and providing some Stringable class that provides type-independent interface to these operations:

class Stringable a where
  length :: a -> Int
  concat :: [a] -> a
  ....
 
instance Stringable String
instance Stringable ByteString
instance Stringable UTF8String
instance Stringable UTF16String