On Fri, Jul 20, 2007 at 11:16:52AM +0400, Bulat Ziganshin wrote:

Friday, July 20, 2007, 3:14:11 AM, you wrote:

...

Is there a reason not to move this, perhaps renaming it in the process, to the base package (or possibly elsewhere in the future, but in the short term I might want to use it in base)?

backward compatibility.

I don't think that's really an issue here. I can't imagine anything would break if we moved it to base without renaming it, and if we did rename it then we could have a module with the old name in unix re-exporting it. Thanks Ian

On Fri, Jul 20, 2007 at 05:20:36PM +0000, Aaron Denney wrote:

On 2007-07-19, Ian Lynagh wrote:

...

I get the feeling I must be missing something, but why is System.Posix.Error in the unix package? It looks to me like it just calls things in the base package, and it works on Windows as far as I can see:

AIUI:

Because it's about the Posix "errno" interface, and nobody uses the posix subsystem of windows because it doesn't interact well with the GUI subsystem?

That might make sense to me, except the getErrno function that actually gets the errorno is in base:Foreign.C.Error, and it (well, under the non-hierarchical name CError) is specified in the FFI spec. In fact, now I look more closely, it also defines a number of throwErrno* functions; it's only the throwErrnoPath* functions that are in unix:System.Posix.Error. This all seems very odd!

I.e. it's a unix interface. Yes C proper defines some error numbers, but that's because C and Unix evolved together. The ones defined in the C standard (as well as posix)

EDOM -- argument out of domain for math function EILSEQ -- illegal byte sequence ERANGE -- "result too large"

are all results from essentially pure library functions, and shouldn't need to throw IO errors.

Both the FFI spec and base:Foreign.C.Error also define many other error numbers. Thanks Ian