On 24 November 2005 01:17, Bulat Ziganshin wrote:

so, as first step i propose to move middle-level code from GHC.Handle to Posix.Internals, join FD type definitions, replace CString with CFilePath where appropriate, and so on. and only after this - make changes specific for windows. i can do it all. what you will say?

Please, go ahead! Your plan to add a new platform-indpendent abstraction layer over the low-level I/O is a good one, I agree with the arguments you put forward. This will indeed make it easier to replace the Handle library in the future, too.

if my changes will be committed only to GHC 6.6 (HEAD) branch, the problem that types of c_* functions is changed will not be a big problem - you anyway change some interfaces between major releases. but now i'm realized that Posix.Internals is part of libraries common for several Haskell compilers. can such changes break their working?

This is a .Internals library, so in theory you only have to look at code in the same package in order to determine whether it breaks anything. It wouldn't hurt to ask the Hugs & nhc98 folk too, just in case.

moreover, i plan to move "throwErrnoIfMinus1RetryOnBlock" to Foreign.C.Error, and sEEK_CUR/sEEK_SET/sEEK_END - to Posix.Internals. can it be done?

I think so, but this module follows the FFI spec, so it should at the least be documented as an extension (fortunately, strictly speaking Foreign.C.Error doesn't have to always follow the FFI spec, but CError does).

-- Support for Unicode filenames and files>4GB #ifdef mingw32_HOST_OS

Note that we have had support for >4Gb files on Unix for quite some time, it is only Windows that is lacking in this regard.

in ALL the places where this feature test must take place. it will document the code and give ability to easily find/edit all these places if this will be needed sometime in the future

If you want to make it clearer, then add new CPP symbols WIN32_UNICODE_FILENAMES WIN32_64BIT_OFFSETS these can be set based on mingw32_HOST_OS for now, but it leaves the possibility of using autoconf later.

can i also ask several questions about "new i/o" library? as i see, this library solves 3 problems:

Each of the questions you asked needs more than a one paragraph answer, and there has been a great deal of discussion on these topics in the past. For now, I'll just say that certain aspects of my prototype I/O library replacement are clearly wrong, and need redesigning (eg. creating multiple streams from a single File isn't implementable). I don't really have the bandwidth to put any serious thought into this right now, but there's nothing stopping you from modifying my proposal and/or coming up with something of your own. Cheers, Simon