CError/IOError issues

[Marcin 'Qrczak' Kowalczyk]

Both ghc and nhc put an optional filename in an IO error value.
ghc concatenates it with the error description (which probably will
come from strerror in CError), nhc stores it separately. Should we
provide a way to supply it?

Similarly there is an optional file handle in the error. ghc stores
it in the IOException value, and nhc will probably do similarly in
future (currently it stores it only in IOError values coming from
the standard library, not in the generic IOErrorC constructor).
Should we provide a way to supply it?

ioeGetErrorString, ioeGetHandle and ioeGetFileName are Haskell98
functions. ghc extracts the filename by searching for a colon in the
stored msg++" "++filename and I've just discovered a bug: there is no
colon there! ioeGetErrorString returns the whole string, together with
a filename. In nhc they are stored separately and ioeGetErrorString
does not include the filename.

Haskell98 says that for "user" errors (those which are raised using
fail) the string returned by ioeGetErrorString is the argument
that was passed to fail; for all other errors, the string is
implementation-dependent (for those who don't remember: fail is a
method of the class Monad). But ghc has IO's fail defined as error,
which is not caught by IO.catch. There is also ioError . userError,
and IMHO it would make sense to treat it the same as IO's fail, as
nhc does. In ghc ioeGetErrorString (userError s) is not s, but it's
error "IO.ioeGetErrorString: not an IO error" - wrong again.

This mess should be cleared out. IMHO ghc should store the error
description in IOException separately from the filename. Haskell98
doesn't provide an interface to extract the location (function name
where the error occurred) from an IOError, so it would be used only
for showing the IOError. fail should use UserErrors, ioeGetErrorString
and friends should understand UserErrors - or UserErrors should be
put with other IOErrors again?

Perhaps CError should provide a function to build an IOError value
(not throwing it) from the function name, errno number, Maybe Handle
and Maybe FilePath. Plus throwErrno as a quick variant which takes the
function name from the parameter, takes the errno number from the errno
variable, sets other two components to Nothing and throws the error.
throwCError would be gone.

I will do all that if it's OK. I just wanted to ask a few simple
questions, and during writing them discovered that IOErrors don't
quite work in ghc as they should.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK