Library/IO

From HaskellWiki
< Library
Revision as of 09:56, 13 March 2007 by Bulatz (talk | contribs)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This page describes my proposal for development of new standard low-level I/O library -- Bulatz 09:29, 13 March 2007 (UTC)

Motivation

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.

Proposal

So, my proposal includes the following:

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


The library itself should include:

  • System.FilePath modules as developed by Neil Mitchell - changed to work via operations of Stringable
  • System.Directory modules from Base - but changed to work via Stringable and to support Unicode filenames (on Win32 this means using one set of functions on NT and another on Win9x)
  • System.File module from Streams/SSC, extended with support of Stringable and files>4GB for Win32
  • System.MappedFile from Streams/SSC, ditto