Re: Hugs vs GHC (again)

Ketil, Ketil Malde wrote:
Dimitry Golubovsky
writes: (Did you intend this for the list?)
Yes, and I re-posted similar message on the list.
I think perhaps the answer is all of the above. The functions could be defined in multiple modules, so that 'ASCII.isSpace' would match the "normal" space character only, while 'Unicode.isSpace' could match all the weird and wonderful stuff in the standard.
And then there might be a bunch of (perhaps autogenerated) locale-matching modules like ISO8859_1, KOI_8 etc.
Well - maybe. Another option is for these to require conversion from to Unicode.
Right, because input of "encoding-specific" functions will be Unicode anyway. And AFAIK conversion from/to unicode may be also contained in localedef files (or for instance in Java CharToXXXX, XXXToChar classes) - I mean that there must be enough information around to build those modules automatically. Except for Unicode itself which would be autogenerated from the Unicode database files like multiple examples of doing this (including mine) that were posted on this list. Dimitry Golubovsky Middletown, CT

Marcin 'Qrczak' Kowalczyk wrote:
"fileRead :: File -> FileOffset -> Integer -> Buffer -> IO ()"
This is unimplementable safely if the descriptor is read concurrently by different processes. The current position is shared.
UNIX98 defines function: extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off_t __offset); Windows has: BOOL ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped ); Where that OVERLAPPED structure contains information where to start read. Seems implementable to me, or am I wrong? -- Gracjan
participants (2)
-
Dimitry Golubovsky
-
Gracjan Polak