On 6/30/07, Duncan Coutts
operations would be a big win, particularly if it were distributed as a standard library. This is the approach that Python's standard libraries take, and it works well.
Yes, we know that both POSIX and Win32 have operations to 'stat' a file and get back some common attributes about it. Of course the intersection of those attributes is not huge, but it at least contains the file size!
I can't help but to think this is exactly the way I don't want to see portable file IO api. I am fairly tired of Windows applications that misuse Windows file rights, and wierd software that got ported from unixy-type systems that interacts very badly because of misuse of file locking. I don't think difference in APIs is trivial. File locking and access rights work very diffrently.
If I had a vote on how Ian might spend his time, it would be on something like this, which would have direct value to programmers by addressing a significant deficit of the current standard libraries. Splitting up the unix package seems more like an inconsequential janitorial task. Given finite resources, I'd prefer to tackle the task with greater benefits.
Though it's also probably more work :-)
It seems to me, one of our main problems is that the current base package cannot depend on the posix/unix or Win32 packages and so we cannot easily implement the portable Haskell APIs on top of the existing posix/win32 api bindings. All the portable stuff is currently implemented on top of C wrappers which interally use cppery to call posix or win32 functions. So fewer people feel able to contribute because most of the code is not Haskell.
Indeed. Also, as Win32 maintainer, I am unsure how far we are supporting old Windowses. When I tentavily asked some people about it, they thought we should continue to support old Windows versions. Unfortunately file rights (in practice all of Security-API) is not available under Win 9x and Me. (But I might have broken somethin anyway, I recall ghc installer having some changes to Win32 to support old Windows versions.)
Perhaps with splitting the base package up we have the opportunity to have the directory & IO stuff live in a package that can depend on either the posix/unix or win32 packages, and implement the portable IO stuff on top of those (probably still using cpp).
I hope portable IO means something that still allows access to important details, and promotes good style. Best regards, Esa Ilari Vuokko