No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Handling Exceptions in Haskell
Abstract
Using a language without exception handling is like driving a car with no brakes and no seatbelt --- things work fine until something goes wrong. You also learn to drive rather carefully. This paper describes an exception handling extension to the Haskell lazy functional language. The implementation turned out to be very easy but we had problems finding a viable semantics for our system. The resulting semantics is a compromise between theoretical beauty and practical utility. 1 Introduction Haskell is an ivory tower language: full of lofty ideas, built on solid semantic foundations, praised by grey-bearded professors and about as much use in the real world as a chocolate teapot. For Haskell to emerge from the ivory tower, it must be possible to write the kinds of programs that less idealistic programmers can write in C, Java, Ada and other useful languages: programs that interact with the real world in interesting ways (using graphics, GUIs, databases, etc) and which are robust enough...
... • Haskell exceptions, as defined in the Haskell 98 standard [Jon03], allow for any type of exception to be thrown and caught, but are limited to use within the IO Monad [Rei98,Pey01]. The types of the functions used to raise and catch exceptions in ...
... • Haskell has seen much work on exceptions in recent years; for example, see [Pey01] for a summary. Exceptions were originally accessible only from within the IO monad [Rei98]; however, the ability to raise exceptions in pure functional code was added later MLP99]. Recently [HMPH05] a new approach to concurrency based on software transactional memory which incorporates both exceptions and interrupts in a more compositional framework has been implemented. ...
... There has been a small urry of recent proposals and papers on exception-handling in Haskell 2,10,9]. The distinctive feature of this paper is its focus on the semantics of the resulting language. ...
... Adding exceptions to a lazy language, as opposed to encoding exceptions in the un-extended language, has received relatively little attention until recently. Dornan and Hammond discussed adding exceptions to the pure (non-I/O) part of a lazy language 1], and there has been a urry of recent activity 2, 10,9]. Drawing on this work, we propose a programming interface, for an exceptions mechanism. ...
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, they offer increased performance or decreased chip area (which amount to much the same thing). This performance/precision tradeoff has not so far been much explored at the programming language level. In this paper we propose a design for imprecise exceptions in the lazy functional programming language Haskell. We discuss several 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. The paper shows how to extend Haskell with exceptions without crippling the language or its compilers. We do not yet have enough experience of using the new mechanism to know whether it strikes an appropriate balance between expressiveness and pwrformance.
... Since the exception is synchronous, we know that re-evaluating this thunk would yield the same exception, so it is safe to overwrite the thunk with a closure which will immediately raise the same exception if demanded. More details are given in [13]. The implementation of asynchronous exceptions differs only in the treatment of thunks; since we cannot be sure that re-evaluating the thunk would raise the same asynchronous exception, we must either revert the thunk to its initial state, or "freeze" it at the point where the exception was received. ...
Asynchronous exceptions, such as timeouts are important for robust, modular programs, but are extremely difficult to program with — so much so that most programming languages either heavily restrict them or ban them altogether. We extend our earlier work, in which we added synchronous exceptions to Haskell, to support asynchronous exceptions too. Our design introduces scoped combinators for blocking and unblocking asynchronous interrupts, along with a somewhat surprising semantics for operations that can suspend. Uniquely, we also give a formal semantics for our system.
... • Handling Exceptions in Haskell [Rei98] describes an exception handling extension to Haskell, as an alternative to the exception monad. ...
This document is a review of the first year of my PhD, working on exceptions and concurrency in Haskell, funded jointly by the University of Nottingham and Microsoft Research Ltd, Cambridge. I shall discuss background information on topics relating to exceptions and concurrency in Haskell as well as relevant papers. I shall also describe the work that I have undertaken in the last year, and outline the research I intend to undertake for my thesis
. Interrupt handling is a tricky business in lazy functional languages: we have to make sure that thunks that are being evaluated can be halted and later restarted if and when they are required. This is a particular problem for implementations which use black-holing. Black-Holing deliberately makes it impossible to revert such thunks to their original state to avoid a serious space leak. Interactive Haskell implementations such as Hugs and hbi catch interrupts and avoid the problem by omitting or disabling black-holing. Batch mode Haskell implementations such as HBC and the Glasgow Haskell Compiler (GHC) avoid this problem by disabling black-holing or by providing no way to catch interrupts. This paper describes a modification to GHC's abstract machine (the Spineless Tagless G-Machine) which simultaneously supports both interrupts and black-holing. 1 Introduction Black-Holing [6] is an important technique for avoiding space leaks in lazy functional languages. When a program starts to ...
We present a new model, based on monads, for performing input/output in a non-strict, purely functional language. It is composable, extensible, efficient, requires no extensions to the type system, and extends smoothly to incorporate mixed-language working and in-place array updates.
"Some half dozen persons have written technically on combinatory logic, and most of these, including ourselves, have published something erroneous. Since some of our fellow sinners are among the most careful and competent logicians on the contemporary scene, we regard this as evidence that the subject is refractory. Thus fullness of exposition is necessory for accurary; and excessive condensation would be false economy here, even more than it is ordinarily."
Category theorists invented monads in the 1960's to concisely express certain aspects of universal algebra. Functional programmers invented list comprehensions in the 1970's to concisely express certain programs involving lists. This paper shows how list comprehensions may be generalised to an arbitrary monad, and how the resulting programming feature can concisely express in a pure functional language some programs that manipulate state, handle exceptions, parse text, or invoke continuations. A new solution to the old problem of destructive array update is also presented. No knowledge of category theory is assumed. 1 Introduction Is there a way to combine the indulgences of impurity with the blessings of purity? Impure, strict functional languages such as Standard ML [Mil84, HMT88] and Scheme [RC86] support a wide variety of features, such as assigning to state, handling exceptions, and invoking continuations. Pure, lazy functional languages such as Haskell [HPW91] or Miranda 1 [T...
For some time functional language researchers have experimented with non-deterministic constructs for these otherwise deterministic languages. One strong motivation to do so is the desire to express necessarily non-deterministic programs, such as operating systems and interactive systems that service requests from several terminals in the order in which they are made. Another motivation is that some parallel algorithms are internally non-deterministic even though their result is not. Since functional languages are claimed to be well suited to parallel programming we certainly wish to be able to express such algorithms. Non-determinism can also be related to program refinement: a non-deterministic function may be considered to be a specification which is refined to a deterministic implementation. We will not address this third aspect here.
The availability of an exception handling mechanism can, with judicious use, greatly aid the clarity of code, allowing the programmer to separate the code to handle unusual situations from the code for the normal case. We describe an exception handling mechanism for a lazy functional language. The system proposed allows expressions which might raise an exception to be evaluated lazily, preserves referential transparency and has no dependence on reduction sequence. Exceptions are parameterised and are statically bound to recovery code. There are two strategies for recovery: resume which replaces the expression signaling an exception with the recovery code; and terminate which replaces the expression signaling the exception at the nearest firewall with the recovery code. Firewalls are used to bound terminate handlers, this allows the preservation of lazy evaluation where exceptions may be raised. A system of priorities is introduced on exceptions, which allow the programmer to indicate which exception is more serious, should a conflict occur. We discuss the approach proposed with reference to present systems.
Handling exceptional occurrences during computation is a problem
in most functional programming languages, even where the computation is
eager and sequential. A version of the error value method is presented
which allows lazy computation with deterministic semantics for parallel
evaluation even in the presence of errors. The realization of this
technique is illustrated by reference PSML, a referentially transparent
variant of standard ML designed for parallel evaluation
We describe the design and use of monadic I/O in Haskell 1.3, the latest revision of the lazy functional programming language Haskell. Haskell 1.3 standardises the monadic I/O mechanisms now available in many Haskell systems. The new facilities allow fairly sophisticated text-based application programs to be written portably in Haskell. The standard provides implementors with a flexible framework for extending Haskell to incorporate new language features. Apart from the use of monads, the main advances over the previous standard are: character I/O based on handles (analogous to ANSI C file pointers), an error handling mechanism, terminal interrupt handling and a POSIX interface. Apart from a tutorial description of the new facilities we include a worked example: a derived monad for combinator parsing. 1 Introduction Haskell 1.3 improves on previous versions of Haskell [12] by adopting an I/O mechanism based on monads [19]. This paper explains the structure of this monadic I/O mechanis...
. Interrupt handling is a tricky business in lazy functional languages: we have to make sure that thunks that are being evaluated can be halted and later restarted if and when they are required. This is a particular problem for implementations which use black-holing. Black-Holing deliberately makes it impossible to revert such thunks to their original state to avoid a serious space leak. Interactive Haskell implementations such as Hugs and hbi catch interrupts and avoid the problem by omitting or disabling black-holing. Batch mode Haskell implementations such as HBC and the Glasgow Haskell Compiler (GHC) avoid this problem by disabling black-holing or by providing no way to catch interrupts. This paper describes a modification to GHC's abstract machine (the Spineless Tagless G-Machine) which simultaneously supports both interrupts and black-holing. 1 Introduction Black-Holing [6] is an important technique for avoiding space leaks in lazy functional languages. When a program starts to ...
Malloc pointers and stable pointers: Improving Haskell's foreign language interface. draft proceedings of Glasgow Functional Programming Workshop
- A Reid
A. Reid. Malloc pointers and stable pointers: Improving Haskell's foreign language
interface. draft proceedings of Glasgow Functional Programming Workshop, July 1994.
The Hugs-GHC libraries. Hugs compiler documentation
- S Marlow
- A Reid
S. Marlow and A. Reid. The Hugs-GHC libraries. Hugs compiler documentation, June
1998.
electronic mail to the Haskell mailing list
- F Henderson
F. Henderson. electronic mail to the Haskell mailing list. June 1998.
Monadic I/O in Haskell 1.3
- K Hammond
- A Gordon
K. Hammond and A. Gordon. Monadic I/O in Haskell 1.3. In Proceedings of the 1995
Haskell Workshop, pages 50{68, La Jolla, California, June 1995.