Imprecise Exceptions, Co-Inductively

In a recent paper, Peyton Jones et al. proposed a design for imprecise exceptions in the lazy functional programming language Haskell PJRH + 99]. The main contribution of the design was that it allowed the language to continue to enjoy its current rich algebra of transformations. However, it does not combine easily with other extensions, most notably that of concurrency. We present an alternative semantics for a lazy functional language with imprecise exceptions which is entirely operational in nature, and combines well with other extensions, such as I/O and concurrency. The semantics is based upon a convergence relation, which describes evaluation, and an exceptional convergence relation, which describes the raising of exceptions. Convergence and exceptional convergence lead naturally to a simple notion of reenement, where a term M is reened by N whenever they have identical convergent behaviour, and any exception raised by N can also be raised by M. We are able to validate many call-by-name equivalences and standard program transformations, including the ubiquitous strictness transformation. 1 Introduction In an earlier paper PJRH + 99] we showed how to add exceptions to a lazy, purely-functional programming language, such as Haskell. There were three key ideas. The rst was to treat an exception as a value rather than as a change of control ow. This idea is fairly standard; for example, the IEEE oating point standard uses it for NaNs. The second idea addressed the question of what meaning to assign to expressions like: (raise e1) + (raise e2): Does this expression deliver the exception e1, or e2? The conventional approach is to x the evaluation order, thus determining which of the two exceptions is delivered. This works well for languages whose evaluation order is already highly constrained because of other eeects, such as assignment or input/output. For languages like Haskell, however, code motion that changes evaluation order is a key transformation , and xing the evaluation order would be a major blow. The alternative we advocated in PJRH + 99] is to say