S. L. Peyton Jones, A. Reid, F. Henderson, C. A. R. Hoare, and S. Marlow. A Semantics for Imprecise Exceptions. In SIGPLAN Conference on Programming Language Design and Implementation, pages 25--36, 1999.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... of this article, but it is important to explore how our approach can be scaled to more expressive languages, such as a simple functional or imperative language, to languages with more than one kind of exception and user defined exceptions, and to other notions of exception, such as imprecise [13] and asynchronous [5] exceptions. Compiler optimisations. The basic compilation method presented in this article can be optimised in a number of ways. For example, we might rearrange the compiled code to avoid the need to jump over handlers in the case of no exceptions being thrown, use a ....

S. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A Semantics For Imprecise Exceptions. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, Atlanta, Georgia, May 1999.

....support for exceptions [24] Better control over the scope of the choice operator is desirable, i.e. more powerful exception handling primitives. One way to do this is to have several kinds of exceptions, but this destroys the confluence of the language unless the evaluation order is fixed [23]. This is because di#erent subexpressions may raise di#erent exceptions, and so the exception that is actually raised depends on which subexpression is evaluated first. There is a tension between rewriting and laziness. A term C fail . will always succeed and never go to the right hand side ....

S. Peyton Jones, A. Reid, T. Hoare, and S. Marlow. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation, pages 25--36, 1999. 8 29

....for program transformation applications. Better control over the scope of the choice operator, i.e. more powerful exception handling primitives. One way to do this is to have several kinds of exceptions, but this destroys the confluence of the language unless the evaluation order is fixed [PRHM99] This is because di#erent subexpressions may raise di#erent exceptions, and so the exception that is actually raised depends on which subexpression is evaluated first. 59 . Non local variable bindings. In Stratego we can write things like: fetch( Foo(x) x That is, walk over a list until ....

Simon Peyton Jones, Alastair Reid, Tony Hoare, and Simon Marlow. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation, pages 25--36, 1999.

....support for exceptions [24] Better control over the scope of the choice operator is desirable, i.e. more powerful exception handling primitives. One way to do this is to have several kinds of exceptions, but this destroys the con uence of the language unless the evaluation order is xed [23]. This is because di erent subexpressions may raise di erent exceptions, and so the exception that is actually raised depends on which subexpression is evaluated rst. There is a tension between rewriting and laziness. A term C fail . will always succeed and never go to the right hand side ....

S. Peyton Jones, A. Reid, T. Hoare, and S. Marlow. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation, pages 25-36, 1999.

....than System.ExitSuccess, an exception is raised. For example, if this happens within the instructions of a build de nition, Take will catch the exception and regard the build routine as having failed. For exception handling, Take relies on GHC s extension of Haskell s standard exception facilities [17,13,18]. As cmd and run are frequently used together, there is a the convenience function exec : String Action String exec = run . cmd A variation on the theme of exec is compile : String Action ( It also enters stdout into the log stream. This is generally useful for invoking compilers or ....

Peyton Jones, S., A. Reid, T. Hoare, S. Marlow and F. Henderson, A semantics for imprecise exceptions, in: Proceedings of the ACM SIGPLAN Conference on Programming Languages Design and Implementation (PLDI'99), 1999.

....the pass, and carries on. This technique proved to be a good way to avoid getting disquali ed because of stupid bugs. The driver also checks for timeout and abandons later passes if it runs out of time. Using the experimental exception handling mechanism that the Glasgow Haskell Compiler provides (Peyton Jones et al. 1999), the driver also catches pattern match failures and suchlike, abandons the o ending pass, and carries on. On the basis of this entry, the Judges awarded Second Prize to Simon Peyton Jones, Simon Marlow, and Sigbjorn Finne. Their ne results and clear exposition leave no doubts that Haskell is ....

Peyton Jones, Simon, Alastair Reid, Tony Hoare, Simon Marlow, and Fergus Henderson. 1999 (May). A semantics for imprecise exceptions. Proceedings of the ACM SIGPLAN '99 Conference on Programming Language Design and Implementation, in SIGPLAN Notices, 34(5):25-36.

....e 1 and e 2 is not equivalent to e 2 and e 1 , because e 1 and e 2 might raise di erent exceptions, one of which might be caught. Such considerations could restrict language implementations, i.e. expressions could not be re arranged unless it can be proven that they raise no exceptions. In [17] a semantics dealing with imprecise exceptions based on the IO monad in Haskell is suggested. This approach is not directly applicable to Java because of the presence of the IO monad, but the issue it tackles is applicable to any language. The question of imprecise exceptions becomes even more ....

Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, and Fergus Henderson. A semantics for imprecise exceptions. In Proceedings of the SIGPLAN Symposium on Programming Language Design and Implementation, May 1999. 83

....e 1 and e 2 is not equivalent to e 2 and e 1 , because e 1 and e 2 might raise different exceptions, one of which might be caught. Such considerations could restrict language implementations, i.e. expressions could not be re arranged unless it can be proven that they raise no exceptions. In [7] a semantics dealing with imprecise exceptions based on the IO monad in Haskell is suggested. This approach is not directly applicable to Java because of the presence of the IO monad, but the issue it tackles is applicable to any language. The question of imprecise exceptions becomes even more ....

Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, and Fergus Henderson. A semantics for imprecise exceptions. In Proceedings of the SIGPLAN Symposium on Programming Language Design and Implementation, May 1999.

No context found.

S. Peyton Jones, A. Reid, C. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation (PLDI'99), pages 25--36, Atlanta, May 1999. ACM.

....98, which comes with an I O library that uses the monadic approach. However, Haskell 98 is not rich enough to deal with the rest of the Awkward Squad (exceptions, concurrency, etc) so we have extended Haskell 98 in a number of experimental ways, adding support for concurrency [35] exceptions [37, 29], and a foreign language interface [36, 11] So far, these developments have mostly been documented in scattered research papers; my purpose in these lectures is to gather some of it together into a coherent account. In what follows, when I refer to Haskell , I will always mean Haskell 98, rather ....

....great semantic bene ts. In particular, by con ning the non deterministic choice to the IO monad we have prevented non determinism from infecting the entire language. 5.2. 3 Semantics of imprecise exceptions This approach to synchronous exceptions in Haskell is described in much more detail in [37]. In particular, the paper describes how to extend a standard denotational semantics to include exceptional values, something we have not treated formally here. We will not discuss that here, for lack of space, but will content ourselves with saying that the meaning function E [ M ] returns ....

[Article contains additional citation context not shown here]

Peyton Jones, S., Reid, A., Hoare, C., Marlow, S., and Henderson, F. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation (PLDI'99) (Atlanta, May 1999), ACM, pp. 25-36.

....98, which comes with an I O library that uses the monadic approach. However, Haskell 98 is not rich enough to deal with the rest of the Awkward Squad (exceptions, concurrency, etc) so we have extended Haskell 98 in a number of experimental ways, adding support for concurrency [35] exceptions [37, 29], and a foreign language interface [36, 11] So far, these developments have mostly been documented in scattered research papers; my purpose in these lectures is to gather some of it together into a coherent account. In what follows, when I refer to Haskell , I will always mean Haskell 98, rather ....

.... . throwTo . return ( H Figure 10: Further extensions for exceptions 5.2. 3 Semantics of imprecise exceptions This approach to synchronous exceptions in Haskell is described in much more detail in [37]. In particular, the paper describes how to extend a standard denotational semantics to include exceptional values, something we have not treated formally here. We will not discuss that here, for lack of space, but will content ourselves with saying that the meaning function . returns either ....

[Article contains additional citation context not shown here]

PEYTON JONES, S., REID, A., HOARE, C., MARLOW, S., AND HENDERSON, F. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation (PLDI'99) (Atlanta, May 1999), ACM, pp. 25--36.

....MVar is always empty. 5 Operational Semantics In this section we give an operational semantics for Concurrent Haskell with exceptions, 2 and then proceed to add in 2 There exists a published operational semantics for Concurrent Haskell [12] a denotational semantics for exceptions in Haskell [13], and an operational semantics for exceptions in Haskell [10] but so far no published semantics links these concepts or describes exceptions in the IO monad. x; y 2 Variable k 2 Constant c 2 Constructor ch 2 Char d 2 Integer e 2 Exception m 2 MVar t; u 2 ThreadId Values V : x j x M ....

....evaluates to some value and raises an exception. Moreover, while convergence is deterministic, the exceptional convergence is not. In other words, a term may raise many different exceptions; which it does raise when evaluated is decided upon at run time. This is the essence of imprecise exceptions [13]. Given this inner semantics, rule (Eval) lifts evaluation in the inner semantics to a transition in the outer system. We stipulate that M 6j V to prevent infinite sequences of the form V Gamma V Gamma V Gamma Delta Delta Delta . Similarly, if the evaluation yields an exception, rule ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proc. PLDI'99, volume 34(5) of ACM SIGPLAN Notices, pages 25--36. ACM Press, May 1999.

....of the above motivations concern the premature abortion of a computation. We do not deal with resumption, in which the interrupted computation can be resumed. 3 Catching and throwing exceptions First, we brie y review our existing extension to support synchronous exception facilities in Haskell [13] 1 : catch : IO a (Exception IO a) IO a raise : Exception a throw : Exception IO a Exceptions can be caught with catch, where the rst argument is the computation to run (i.e. the scope of the catch) and the second argument is the exception handler. In non IO code, ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proc. PLDI'99, volume 34(5) of ACM SIGPLAN Notices, pages 25-36. ACM Press, May 1999.

....low latency and low overhead for multiple simultaneous clients that is essential for good server performance. Fault tolerance is supported in the form of Haskell s type system, which guards against crashes and increases con dence in code correctness, and recent extensions to support exceptions [6] which provide useful facilities for coping with run time errors. Asynchronous Exceptions [3] allow concise implementations of important features such as timeouts, as we shall see in Section 4. Asynchronous exceptions are also useful for allowing the server to respond to external stimulus, such ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proc. PLDI'99, volume 34(5) of ACM SIGPLAN Notices, pages 25-36. ACM Press, May 1999. 10

....with an I O library that uses the monadic approach. However, Haskell 98 is not rich enough to deal with rest of the Awkward Squad (exceptions, concurrency, etc) so we have extended Haskell 98 in a number of experimental ways, adding support for concurrency [Peyton Jones et al. 1996] exceptions [Peyton Jones et al. 1999, Marlow et al. 2000] and a foreign language interface [Peyton Jones et al. 1998, Finne et al. 1999] So far, these developments have mostly been documented in scattered research papers; my purpose in these lectures is to gather some of it together into a coherent account. In what follows, ....

.... =N 2 ) M 6= catch N 1 N 2 ) fE 1 [throwTo t e]g s j fE 2 [M ]g t fE 1 [return ( g s j fE 2 [ioError e]g t (THROWTO) Figure 9: Further extensions for exceptions 6.4. 1 Semantics of imprecise exceptions This approach to synchronous exceptions in Haskell is described in much more detail in [Peyton Jones et al. 1999]. In particular, the paper describes how to extend a standard denotational semantics to include exceptional values, something we have not treated formally here. We will not discuss that here, for lack of space, but will content ourselves with saying that the meaning function E [ M ] returns ....

[Article contains additional citation context not shown here]

Peyton Jones, S., Reid, A., Hoare, C., Marlow, S., and Henderson, F. (1999). A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation (PLDI'99), pages 25-36, Atlanta. ACM.

....plenty of relevant attributes to bring to the party: Concurrent Haskell [5] provides a lightweight concurrency model that helps to provide the low latency and low overhead for multiple simultaneous clients that is essential for good server performance. Recent extensions to support exceptions [6] provide useful facilities for coping with runtime errors. Asynchronous Exceptions [3] allow concise implementations of important features such as timeouts, as we shall see in Section 4. Asynchronous exceptions are also useful for allowing the server to respond to external stimulus, such as ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proc. PLDI'99, volume 34(5) of ACM SIGPLAN Notices, pages 25-36. ACM Press, May 1999.

....possible with transformational patterns when they are just reduced to pattern guards. Therefore, we have to provide an independent semantics de nition. One possible way to go is to de ne pattern matching within a Haskell version that accounts for exceptions. A proposal for exceptions was made in [13], giving a precise semantics together with an ecient implementation. Pattern match failure could be de ned in that context to raise a Fail exception, and pattern matching had to catch Fail exceptions to select function equations. In that proposal catching exceptions leads, in general, to ....

....and e2 result in two di erent exceptions. Now what should be the result of e1 e2 If we avoid to x the evaluation order, all we can do is to either de ne to make a non deterministic choice or to return the set of all exceptions raised anywhere within e1 and e2. The last proposal was made in [13]. Even when dealing with exception sets, checking for a particular exception re introduces non determinism. However, in a framework where Fail is the only exception one could also think of just checking whether an exception has occurred at all or not. This eliminates non determinism to a large ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A Semantics for Imprecise Exceptions. In ACM Conf. on Programming Languages Design and Implementation, pages 25-36, 1999.

.... t = if e then (y,z) else (z,y) It looks as though t has the CPR property, but it would be wrong to blindly apply the worker wrapper transformation to t, because that would give: t : Int, Int) t = case tw of (# p,q #) p,q) 4 In a more re ned semantics, error raises an exception [7], but everything we say here remains valid. 4 tw : # Int,Int #) tw = if e then (# y,z #) else (# z,y #) In the original de nition, t might never be evaluated, and hence e might not either. But in the new program tw is an unboxed value, so its evaluation cannot be delayed delaying ....

SL Peyton Jones, A Reid, CAR Hoare, S Marlow, and F Henderson. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation (PLDI'99), pages 25-36, Atlanta, May 1999. ACM.

....of the above motivations concern the premature abortion of a computation. We do not deal with resumption, in which the interrupted computation can be resumed. 3 Catching and throwing exceptions First, we brie y review our existing proposal for adding synchronous exception facilities to Haskell [13] 1 : catch : IO a (Exception IO a) IO a raise : Exception a throw : Exception IO a Exceptions can be caught with catch, where the rst argument is the computation to run (i.e. the scope of the catch) and the second argument is the exception handler. In non IO code, ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proc. PLDI'99, volume 34(5) of ACM SIGPLAN Notices, pages 25-36. ACM Press, May 1999.

....matching failure is not possible with transformational patterns when they are just reduced to pattern guards. Therefore, we need a separate semantics de nition. One possible way to go is to de ne pattern matching within a Haskell version that accounts for exceptions. Such a proposal was made in [12], giving a precise semantics together with an ecient implementation. Pattern match failure can be de ned in that context to raise a Fail exception, and pattern matching had to catch Fail exceptions to select function equations. Although, in general, catching exceptions leads to non determinism, ....

S. L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A Semantics for Imprecise Exceptions. In ACM Conf. on Programming Languages Design and Implementation, pages 25-36, 1999.

....Consider the following function: chr : Int Char chr (MkInt i) if (i =0 i =255) then MkChar i else error Bad arg to chr The function error prints a message and brings execution to a halt 4 . Semantically, its value is just . 4 In a more re ned semantics, error raises an exception [6], but everything we say here remains valid. Does chr have the CPR property Clearly, yes If it returns at all, it certainly returns a constructed product, and that is all that matters. So when performing CPR analysis, we should treat a call to error as having the CPR property. Clearly, we want ....

SL Peyton Jones, A Reid, CAR Hoare, S Marlow, and F Henderson. A semantics for imprecise exceptions. In ACM Conference on Programming Languages Design and Implementation (PLDI'99), pages 25-36, Atlanta, May 1999. ACM.

No context found.

S. L. Peyton Jones, A. Reid, C. A. R. Hoare, S. Marlow, and F. Henderson, A semantics for imprecise exceptions, ACM SIGPLAN Notices 34 (1999), no. 5, 25-36, Proc. of PLDI'99.

No context found.

S. L. Peyton Jones, A. Reid, C. A. R. Hoare, S. Marlow, and F. Henderson, A semantics for imprecise exceptions, ACM SIGPLAN Notices 34 (1999), no. 5, 25--36, Proc. of PLDI'99.

....cost of introducing SEQ nodes at the expense of making resumable black holes more complex. This extra complexity is most keenly felt in the garbage collector which is already quite complex enough 5. 3 Exception handling We recently extended the STG machine with an exception handling mechanism [10, 11] which uses the update list to store exception handlers as well as updatees. When the evaluator finds an exception handler on the update list as it is trying to return a value, it removes the exception handler and tries again. This requires the following change to our revertible black holing ....

....part of Haskell where black holing is used) because the the lack of side effects limits the problems to those introduced by the implementation. In the imperative subset of Haskell, the programmer must write their own cleanup code we recently added exception handling to Haskell for this purpose [10, 11]. Multiscalar processors perform a considerable amount of speculative evaluation and must clean up their internal state when a speculative evaluation is terminated. For example, Breach et al. 1] describe an architecture which tracks dependencies between different stages of the processor. ....

S. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Programming Languages Design and Implementation. ACM press, May 1999.

No context found.

S. L. Peyton Jones, A. Reid, F. Henderson, C. A. R. Hoare, and S. Marlow. A Semantics for Imprecise Exceptions. In SIGPLAN Conference on Programming Language Design and Implementation, pages 25--36, 1999.

No context found.

S. Peyton Jones, A. Reid, F. Henderson, T. Hoare, and S. Marlow. A semantics for imprecise exceptions. In Proceedings of the ACM SIGPLAN 1999.

No context found.

Simon L. Peyton Jones, Alastair Reid, Fergus Henderson, C. A. R. Hoare, and Simon Marlow. A Semantics for Imprecise Exceptions. In SIGPLAN Conference on Programming Language Design and Implementation, pages 25--36, 1999.

No context found.

Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, and Fergus Henderson. A semantics for imprecise exceptions. In Proceedings of the SIGPLAN Symposium on Programming Language Design and Implementation, May 1999. 83

No context found.

Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, and Fergus Henderson. A semantics for imprecise exceptions. In Proceedings of the SIGPLAN Symposium on Programming Language Design and Implementation, May 1999.

No context found.

Simon L. Peyton Jones, Alastair Reid, Fergus Henderson, C. A. R. Hoare, and Simon Marlow. A Semantics for Imprecise Exceptions. In SIGPLAN Conference on Programming Language Design and Implementation, pages 25--36, 1999.

No context found.

Simon L. Peyton Jones, Alastair Reid, Fergus Henderson, C. A. R. Hoare, and Simon Marlow. A semantics for imprecise exceptions. In SIGPLAN Conference on Programming Language Design and Implementation, pages 25--36, 1999.

No context found.

Simon L. Peyton Jones, Alastair Reid, Fergus Henderson, C. A. R. Hoare, and Simon Marlow. A semantics for imprecise exceptions. In SIGPLAN Conference on Programming Language Design and Implementation, pages 25--36, 1999.

No context found.

S. P. Jones, A. Reid, C. A. R. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proceedings of the SIGPLAN Symposium on Programming Language Design and Implementation (PLDI'99), Atlanta, 1999. 13

No context found.

S. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Conference on Programming Language Design and Implementation, PLDI'99, pages 25--36, Atlanta, Georgia, 1999.

No context found.

S. Peyton Jones, A. Reid, F. Henderson, T. Hoare, and S. Marlow. A semantics for imprecise exceptions. In Proceedings of the ACM SIGPLAN 1999.

No context found.

S. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A Semantics For Imprecise Exceptions. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, Atlanta, Georgia, May 1999.

No context found.

S.L. Peyton Jones, A. Reid, T. Hoare, S. Marlow, and F. Henderson. A semantics for imprecise exceptions. In Proc Programming Languages Design and Implementation (PLDI'99), Atlanta, 1999.

No context found.

A.D. Gordon, S. Marlow and S.L. Peyton Jones, "A Semantics for Imprecise Exceptions ", Proc. Symposium on Principles of Programming Languages (POPL 2000), January 2000.

No context found.

Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, and Fergus Henderson. A semantics for imprecise exceptions. In Proceedings of the 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), SIGPLAN Notices, Atlanta, Georgia, USA, May 1999. SIGPLAN Notices 34(5).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC