On 28-Sep-1999, Alastair Reid <[EMAIL PROTECTED]> wrote:
>
> Fergus Henderson <[EMAIL PROTECTED]> replied:
> > What existing functions for testing IOErrors?
> > Apart from the Eq and Show classes, Haskell 98 doesn't define any, AFAIK.
>
> The IO library defines these functions.
> (http://haskell.cs.yale.edu/onlinelibrary/io.html)
>
> isAlreadyExistsError :: IOError -> Bool
> isDoesNotExistError :: IOError -> Bool
> isAlreadyInUseError :: IOError -> Bool
> isFullError :: IOError -> Bool
> isEOFError :: IOError -> Bool
> isIllegalOperation :: IOError -> Bool
> isPermissionError :: IOError -> Bool
> isUserError :: IOError -> Bool
> ioeGetErrorString :: IOError -> String
> ioeGetHandle :: IOError -> Maybe Handle
> ioeGetFileName :: IOError -> Maybe FilePath
Oh, of course. Thanks for the correction. (I searched the Haskell 98
Report but I forgot to search the Haskell 98 Library Report.)
...
> I was going to suggest that we redefine isAlreadyExistsError and
> friends to return true if the associated error is a member of the set.
> But if we do this, what do we do with ioeGetErrorString and friends?
Deprecate them.
Define them to return the value associated with the first matching
exception, but deprecate them, and instead provide alternatives
that work with sets of exceptions.
> > (b) allow throwing and catching of dynamically typed values,
> > e.g. using an interface like the Hugs/ghc Dynamic library
>
> Despite having written a good deal of the Hugs-GHC Dynamic library[2],
> I'm wary of making it part of the standard because it is limited to
> handling monomorphic values only: no polymorphism, no overloading.
I'm not entirely certain that I understand what you mean by
"no polymorphism, no overloading".
If you want to put a polymorphic overloaded function into a Dynamic,
you can just put it in a wrapper data structure and put the wrapper
into a Dynamic, and then you can get that wrapper out of the
Dynamic and then get the polymorphic overloaded function out of
the wrapper. (This presumes that the language supports first-class
polymorphism in data structures, but ghc supports that, and I think
it is likely that Haskell 200X will.)
I presume, then, that what you are talking about the difficulty of
putting a monomorphically typed value into a Dynamic and then
later extracting it with a polymophic or overloaded type.
Extracting values with polymorphic types can be solved using
existential types. This technique is used in the Mercury standard
library (versions rotd-1998-11-19 and greater). Using this technique
can be a little cumbersome, but it gets the job done. It does require
a small extension to the current Dynamic interface, specifically a
function analagous to the `univ_value' function in the Mercury standard
library, but that extension would be trivial to implement once you have
existential types.
Extracting values with overloaded types requires what I called
"dynamic type class casts". I agree that the lack of support for
this is a problematic limitation.
So, if a better solution comes along before Haskell 200X is finalized,
that would be great. But failing that, I think something like the
Hugs-GHC Dynamic library is certainly much better than using a
non-extensible Exception type, even if does not solve all the problems
that we would like it to solve.
> I'm also a little leery of the lack of structure that would result
> from using dynamic typing to provide extensibility. The hierarchial
> organisation of exceptions in Java and other OO languages seems to be
> a good match to the task.
Well, C++ and Java certainly use dynamic typing in their exception handling.
The difference is that those languages support the equivalent of
dynamic type class casts, whereas the Hugs/ghc Dynamic library does not.
Certainly it would be nicer to impose more structure.
And if/when Haskell gets support for type class casts or something
equivalent, then as you say we can do that using Haskell's type
class system.
But if dynamic type class casts or something with similar functionality
don't arrive in time for Haskell 200X, then we will need an interim
solution. Currently the only alternative is to encode all exception
types into strings. Using Dynamic could hardly be worse. If the
choice is between strings and Dynamic, then I'll choose Dynamic every
time.
Note that Ada 95 used strings, and so the Ada 95 experts in
comp.lang.ada recommend using serialization techniques to encode
arbitrary data types in strings for the purposes of exception
handling. I surely hope that Haskell 200X experts don't have to
recommend the same advice.
> (Though, again, how does this interact with having sets of errors?)
I don't think that is a problem for hierarchical classification.
You just have to apply the dynamic type class cast (or equivalent)
to every member of the set and collect the set of results.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
