> On 08-Sep-1999, Alastair Reid <[EMAIL PROTECTED]> wrote:
> > What
> > I'd like (in some future version of Haskell) is an IOError constructor
> > which lets me merge two IOErrors together and appropriate operations
> > to test for it and, perhaps, take it apart:
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
The idea of these functions is to make use of the type abstract and,
hence, simplify extension of the type. (I'm not sure it achieves this
because existing code that carefully checks for the above errors would
probably break if we added a new kind of error.)
> If you're suggesting that Eq or Show be undefined for IOErrors that
> represent sets of exceptions, then I would have to disagree...
No problem with Show - I use it all the time.
I think having and using Eq is ok (though it defeats whatever
abstraction the above operations provide). Obviously we'd want to add
an "elem"-like function as well if we have sets of exceptions.
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?
> The exception handling in Haskell 98 needs substantial work, IMHO.
I'd certainly agree with that. My suggestion was meant as a minimal
change to what is already there.
> IMHO Haskell 200X should pick up the Hugs/ghc extensions related to
> exception handling, or something along those lines, in particular:
> (a) allow throwing exceptions from arbitrary code, not just from within
> the IO monad
Fergus and I are in complete agreement here - but then we are
coauthors on a paper[1] that describes how to do it :-) I think this
is quite a minor change - but very, very important if you're trying
to do real things with Haskell.
> (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 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. (Though, again, how does this interact
with having sets of errors?)
It is probably possible to encode such a hierarchy using Haskell's
type classes but I worry that the lack of overloading in the present
Dynamic library would prevent us from combining the two. (Anyone care
to prove me wrong on this claim?)
--
Alastair Reid [EMAIL PROTECTED] http://www2.cs.utah.edu/~reid/
[1] http://www2.cs.utah.edu/~reid/except-pldi.ps.gz
@inproceedings{ReidA:PLDI99
,author="S.L. {Peyton Jones} and A. Reid and Tony Hoare and Simon Marlow and Fergus
Henderson"
,title="A semantics for imprecise exceptions"
,booktitle = "Programming Languages Design and Implementation (PLDI'99)"
,organization = "ACM press"
,year = "1999"
,month ="May"
,pages="25-36"
,abstract="
Some modern superscalar microprocessors provide only imprecise
exceptions. That is, they do not guarantee to report the same
exception that would be encountered by a straightforward
sequential execution of the program. In exchange, the offer
increased performance or decreased area (which amount to much the
same thing). This performance/precision tradeoff has not so far
been explored at the programming langauge level. In this paper we
propose a design for imprecise exceptions in the lazy functional
programming language Haskell. We discuss various simpler designs,
and conclude that imprecision is essential if the language is
still to enjoy its current rich algebra of transformations. We
sketch a precise semantics for the language extended with
exceptions. From the functional programming point of view, the
paper shows how to extend Haskell with exceptions without
crippling the language or its compilers. From the point of view
of the wider programming language community, we pose the question
of whether precision and performance can be traded off in other
languages too.
"
}
[2] http://haskell.cs.yale.edu/ghc/docs/latest/libraries/libs.html
