Exception handling is provided by most modern programming languages. It allows to deal with anomalous or exceptional events which require special processing. In computer algebra, exception handling is an e cient way to implement the dynamic evaluation paradigm: for instance, in linear algebra, dynamic evaluation can be used for applying programs which have been written for matrices with coe cients in a eld to matrices with coe cients in a ring. Thus, a proof system for computer algebra should include a treatement of exceptions, which must rely on a careful description of a semantics of exceptions. The categorical notion of monad can be used for formalizing the raising of exceptions: this has been proposed by Moggi and implemented in Haskell. In this paper, we provide a proof system for exceptions which involves both raising and handling, by extending Moggi's approach. Moreover, the core part of this proof system is dual to a proof system for side e ects in imperative languages, which relies on the categorical notion of comonad. Both proof systems are implemented in the Coq proof assistant.
Using exceptions is an e cient way to simultaneously compute with dynamic evaluation in exact linear algebra. For instance, for computing the rank of a matrix, a program written for matrices with coe cients in a eld can easily be modi ed by adding an exception treatment in order to be applied to a matrix with coe cients in a ring: the exception mechanism provides an automatic case distinction whenever it is required. The question that arises then is how to prove correctness of the new algorithm. It would be nice to design proofs with two levels, as we designed the algorithms: a rst level without exceptions, then a second level taking the exceptions into account. In this paper, we propose a proof system following this principle.
Exceptions form a computational e ect, in the sense that a syntactic expression f : X ! Y is not always interpreted as a function Jf K : JXK ! JY K (where, as usual, the sets JXK and JY K denote the interpretations of the types X and Y ). For instance a function which raises an exception can be interpreted as a function Jf K : JXK ! JY K + Exc where Exc is the set of exceptions and \+" denotes the disjoint union. In a programming language, exceptions usually di er from errors in the sense that it is possible to recover from an exception while this is impossible for an error; thus, exceptions have to be both raised and handled.
The fundamental computational e ect is the evolution of states in an imperative language, when seen from a functional point of view. There are several frameworks for combining functional and imperative programming: the e ect systems classify the expressions according to the way they interact with the store [11], while the Kleisli category of the monad of states (X St )St (where St is the set of states) also provides a classi cation of expressions [14]; indeed, both approaches are related [20]. Lawvere theories were proposed for dealing with the operations and equations related to computational e ects [16,12]. Another related approach, based on the fact that the state is observed, relies on the classi cation of expressions provided by the coKleisli category of the comonad of states X St and its associated Kleisli-on-coKleisli category [4].
The treatment of exceptions is another fundamental computational e ect. It can be studied from the point of view of the monad of exceptions X + Exc (where Exc is the set of exceptions), or with a Lawvere theory, however in these settings it is di cult to handle exceptions because this operation does not have the required algebraicity property [17,18], in contrast with raising exceptions, looking up and updating states. This makes exceptions much more di cult to formalize than other e ects in the Lawvere theory framework. This issue has been circumvented in [19] in order to get a Hoare logic for exceptions, in [13] by using both algebras and coalgebras and in [18] by introducing handlers. The formalization of exceptions can also be made from a coalgebraic point of view [10]. In this paper we extend Moggi's original approach: we use the classi cation of expressions provided by the Kleisli category of the monad of exceptions and its associated coKleisli-on-Kleisli category; moreover, we use the duality between states and exceptions discovered in [3]. However, it is not necessary to know about monads or comonads for reading this paper: the de nitions and results are presented in an elementary way, in terms of equational theories.
In Section 2 we give a motivating example for the use of exceptions as an e cient way to compute with dynamic evaluation in exact linear algebra. Then in Section 3 we de ne the syntax of a simple language for dealing with exceptions. The intended denotational semantics is described in Section 4: we dissociate the core operations for switching between exceptions and non-exceptional values, on one side, from their encapsulation in the raising and handling operations, on the other side. In Section 5 we add decorations to the syntax, in order to classify the expressions of the language according to their interaction with the exceptions. Decorations extend the syntax much like compiler quali ers or speci ers (e.g., like the throw annotation in C++ functions' signatures). In addition, we also decorate the equations, which provides a proof system for dealing with this decorated syntax. The main result of the paper is that this proof system is sound with respect to the semantics of exceptions (Theorem 1). A major property of this new proof system is that we can separate the veri cation of the proofs in two steps: a rst step checks properties of the programs whenever there is no e ect, while a second step takes the e ects into account via the decorations. Several properties of exceptions have been proven using this proof system, and these proofs have been veri ed in the Coq proof assistant. 2
Rank algorithms play a fundamental role in computer algebra. For instance, computing homology groups of simplicial complexes reduces to computing ranks and integer Smith normal forms of the associated boundary matrices [6]. One of the most e cient method for computing the Smith normal form of such boundary matrices also reduces to computing ranks but modulo the valence, a product of the primes involved in the Smith form [7]. Now rank algorithms (mostly Gaussian elimination and Krylov based methods) work well over elds (note that Gaussian elimination can be adapted modulo powers of primes [7, §5.1]). Modulo composite numbers, zero divisors arise. Gauss-Bareiss method could be used but would require to know the determinant in advance, with is more di cult than the valence. The strategy used in [7] is to factor the valence, but only partially (factoring is still not polynomial). The large remaining composite factors will have very few zero divisors and thus Gaussian elimination or Krylov methods will have very few risks of falling upon them. Thus one can use dynamic evaluation: try to launch the rank algorithm modulo this composite number with large prime factors and \pretend" to be working over a eld [8]. In any case, if a zero divisor is encoutered, then the valence has been further factored (in polynomial time!) and the algorithm can split its computation independently modulo both factors. An e ective algorithm design, here in C++, enabling this dynamic evaluation with very little code modi cation, uses exceptions: 1. Add one exception at the arithmetic level, for signaling a tentative division by a zero divisor, see Fig. 1. inline Integer invmod(const Integer& a, const Integer& m) f
if (gcd != 1) throw ZmzInvByZero(gcd); return u>0?u:u+=m; g 2. Catch this exception inside the rank algorithm and throw a new exception with the state of the rank iteration, see Fig. 2 (in our implementation the class zmz wraps integers modulo m, the latter modulus being a static global variable). 3. Then it is su cient to wrap the rank algorithm with a dynamic evaluation, splitting the continuation modulo both factors, see Fig. 3. try f
invpiv = zmz(
throw GaussNonInvPivot(e.getGcd(), k, currentrank); void DynEvalRank(RankPairs& vectranks, size t addedrank, ZmzMatrix& A) f try f long rank = gaussrank(A); // in place modi cations of A vectranks.push back(RankPair(rank+addedrank, zmz::getModulus()) ); g catch (GaussNonInvPivot e) f // Split long mymodulus1 = zmz::getModulus()/e.getGcd(); long mymodulus2 = zmz::getModulus()/mymodulus1; // Homomorphism on the (n-k) (m-k) remaining block zmz::setModulus( mymodulus1 );
DynEvalRank(vectranks, e.getCurrentRank(), M1); // Homomorphism on the (n-k) (m-k) remaining block zmz::setModulus( mymodulus2 );
DynEvalRank(vectranks, e.getCurrentRank(), M2); g g
The advantage of using exceptions over other software design is twofold: rst, throwing an exception at the arithmetic level and not only on the inverse call in the rank algorithm allows to prevent that other unexpected divisions by zero divisors go unnoticed; second, re-throwing a new exception in the rank algorithm allows to keep its speci cations unchanged. It also enables to keep the modi cations of rank algorithms to a minimum and to clearly separate normal behavior with primes from the exceptional handling of splitting composite moduli.
In the following, we propose a proof system with decorations, so that proofs can easily be made in two steps: a rst step without exceptions, that is, just preserving an initial proof of the rank algorithm; then a second level taking the exceptions into account.
The syntax for exceptions in computer languages depends on the language: the keywords for raising exceptions may be either raise or throw, and for handling exceptions they may be either handle, try-with, try-except or try-catch, for instance. In this paper we rather use throw and try-catch. The syntax for dealing with exceptions may be described in two parts: a basic part which deals with the basic data types and an exceptional part for raising and handling exceptions.
The language we develop is quite close to the Ynot language [15]. Like Ynot, our approach is "a generalization of the well-known ideas from type-and-e ect systems and their monadic counterparts". However, we can use comonads as well as monads, and we o er more modularity: in Ynot there is a single monad encompassing all e ects, while we are able to compose e ects, thus enabling to prove programs in several simpler stages.
The basic part of our syntax is a signature Sigbase , made of types (or sorts) and operations. The exceptional types form a subset T of the set of types of Sigbase . For instance in C++ any type (basic type or class) is an exceptional type, while in Java there is a base class for exceptional types, such that the exceptional types are precisely the subtypes of this base class. Now, we assume that some basic signature Sigbase and some set of exceptional types T have been chosen.
The signature Sigexc for exceptions is made of Sigbase together with the operations for raising and handling exceptions, as follows.
De nition 1. The signature for exceptions Sigexc is made of Sigbase with the following operations: a raising operation for each exceptional type T and each type Y :
throwT;Y : T ! Y ; and a handling operation for each Sigexc-term f : X ! Y , each non-empty list of exceptional types (Ti)1 i n and each family of Sigexc-terms (gi : Ti ! Y )1 i n: tryff g catch fTi ) gig1 i n : X ! Y :
An important, and somewhat surprising, feature of a language with exceptions is that all expressions in the language, including the try-catch expressions, propagate exceptions. Indeed, if an exception is raised before some try-catch expression is evaluated, this exception is propagated. In fact, the catch block in a try-catch expression may recover from exceptions which are raised inside the try block, but the catch block alone is not an expression of the language. This means that the operations for catching exceptions are private operations: they are not part of the signature for exceptions. More precisely, the operations for raising and handling exceptions can be expressed in terms of a private empty type and two families of private operations: the tagging operations for creating exceptions and the untagging operations for catching them (inside the catch block of any try-catch expression). The tagging and untagging operations are called the core operations for exceptions. They are not part of Sig exc, but the interpretations of the operations for raising and handling exceptions, which are part of Sig exc, are de ned in terms of the interpretations of the core operations. The meaning of the core operations is given in Section 4.
De nition 2. Let Sig exc be the signature for exceptions. The core of Sig exc is the signature Sig core made of Sig base with a type 0 called the empty type and two operations for each exceptional type T :
tagT : T ! 0 and untagT : 0 ! T where tagT is called the exception constructor or the tagging operation and untagT is called the exception recovery or the untagging operation. 4
In this Section we de ne a denotational semantics for exceptions which relies on the common semantics of exceptions in various languages, for instance in C++ [1, Ch. 15], Java [9, Ch. 14] or ML.
The basic part of the syntax is interpreted in the usual way: each type X is interpreted as a set JXK and each operation f : X ! Y of Sig base as a function Jf K : JXK ! JY K. But, when f : X ! Y in Sig exc is a raising or handling operation, or when f : X ! Y in Sig core is a tagging or untagging operation, it is not interpreted as a function Jf K : JXK ! JY K: this corresponds to the fact that the exceptions form a computational e ect. The distinction between ordinary and exceptional values is discussed in Subsection 4.1. Then, denotational semantics of raising and handling exceptions are considered in Subsections 4.2 and 4.3, respectively. We assume that some interpretation of Sig base has been chosen. 4.1
Ordinary values and exceptional values In order to express the denotational semantics of exceptions, a fundamental point is to distinguish between two kinds of values: the ordinary (or non-exceptional) values and the exceptions. It follows that the operations may be classi ed according to the way they may, or may not, interchange these two kinds of values: an ordinary value may be tagged for constructing an exception, and later on the tag may be cleared in order to recover the value; then we say that the exception gets untagged. Let Exc be a set, called the set of exceptions. For each set A, the set A + Exc is the disjoint union of A and Exc and the canonical inclusions are denoted normal A : A ! A + Exc and abrupt A : Exc ! A + Exc. For each functions f : A ! B and g : Exc ! B, we denote by [f jg] : A + Exc ! B the unique function such that [f jg] normal A = f and [f jg] abrupt A = g.
exceptional value if it is in Exc. A function ' : A + Exc ! B + Exc: { raises an exception if there is some x 2 A such that '(x) 2 Exc. { recovers from an exception if there is some e 2 Exc such that '(e) 2 B. { propagates exceptions if '(e) = e for every e 2 Exc.
Clearly, a function ' : A + Exc ! B + Exc which propagates exceptions may raise an exception, but cannot recover from an exception. Such a function ' is characterized by its restriction 'jA : A ! B + Exc, since its restriction on exceptions 'jExc : Exc ! B + Exc is the inclusion abrupt B of Exc in B + Exc.
In the denotational semantics for exceptions, we will see that a term f : X ! Y of Sig exc or Sig core may be interpreted either as a function Jf K : JXK ! JY K or aHsoawfeuvnecr,tiionnaJlfl Kc a:sJeXs,Kit!isJYpoKs+siEblxec toor caosnavfeurtncJtfioKntoJfaK f:uJnXctKi+onEfxrcom! JJXY KK++EExxcc. to JY K + Exc, as follows.
{ every function ' : A ! B gives rise to ' = normal B ' : A ! B + Exc, { every function : A ! B + Exc gives rise to = [ jabrupt B] : A + Exc !
{ it follows that every function ' : A ! B gives rise to ' = ( ') = [normal B 'jabrupt B] = ' + id Exc : A + Exc ! B + Exc, which is equal to ' on A and which propagates exceptions.
Since the upcasting conversions are safe (i.e., injective), when there is no ambiguity the symbols , and may be omitted. In this way, for each f : X ! Y and g : Y ! Z, whatever their e ects, we get Jf K : JXK + Exc ! JY K + Exc and JagnKd: SJiYgKco+reEcxacn!beJZinKt+erEpxrect,ewdhbicyh crasnt bcoencvoemrtpinogsedth. eTihnutse,rpevreetrayttioenrmofofeaScighexocf its components f : X ! Y to a function Jf K : JXK + Exc ! JY K + Exc. For Sig exc , this coincides with the Kleisli composition associated to the exception monad A + Exc [14].
We will also use the following conversion.
{ every function : A + Exc ! B + Exc gives rise to = normal A : A !
This conversion is unsafe: di erent 's may give rise to the same . 4.2
Tagging and raising exceptions Raising exceptions relies on the interpretation of the tagging operations. The interpretation of the empty type 0 is the empty set ;; thus, for each type X the interpretation of 0 + X can be identi ed with JXK.
De nition 6. Let Exc be the disjoint union of the sets JT K for all the exceptional types T . Then, for each exceptional type T , the interpretation of the tagging operation tagT : T ! 0 is the coprojection function
JtagT K : JT K ! Exc : Thus, the tagging function JtagT K : JT K ! Exc maps a non-exceptional value (or parameter ) a 2 JT K to an exception JtagT K(a) 2 Exc. We can now de ne the raising of exceptions in a programming language.
of the raising operation throwT ;Y is the tagging function JtagT K followed by the inclusion of Exc in JY K + Exc:
JthrowT ;Y K = abrupt JY K JtagT K : JT K ! JY K + Exc : 4.3
Untagging and handling exceptions Handling exceptions relies on the interpretation of the untagging operations for clearing the exception tags.
operation untagT : 0 ! T is the function which satis es for each exceptional type R:
JuntagT K JtagRK =
JuntagT K : Exc ! J K
T + Exc ; (normal T
J K abrupt JT K JtagRK when R = T when R 6= T Thus, the untagging function JuntagT K, when applied to any exception e, rst tests whether e is in JT K; if this is the case, then it returns the parameter a 2 JT K smuacihn tohfatJuen=tagJTtaKgTisK(Ea)x,c,otJhuenrtwaigsTe Kitispruonpiaqguaetleys dtheteeremxcienpetdiobnye.itSsinrecsetrtihcetiodnosto all the exceptional types, and therefore by the equalities in De nition 8. For handling exceptions of types T1; : : : Tn, raised by the interpretation of some term f : X ! Y of Sig exc, one provides for each i in f1; : : : ; ng a term gi : Ti ! Y of Sig exc (thus, the interpretation of gi may itself raise exceptions). Then the handling process builds a function which rst executes f , and if f returns an exception then maybe catches this exception. The catching part encapsulates some untagging functions, but the resulting function always propagates exceptions. De nition 9. For each term f : X ! Y of Sig exc, and each non-empty lists (Ti)1 i n of exceptional types and (gi : Ti ! Y )1 i n of terms of Sig exc, let (recover i)1 i n denote the family of functions de ned recursively by: : R T + Exc:
J K ! J K recover i = ( [ JgnK j abrupt Y ] untagTn [ JgiK j recover i+1 ] untagTi when i = n when i < n
: Exc ! Y + Exc Jtry ff g catch fTi ) gig1 i nK = [ normal Y j recover 1 ] f :
J K It should be noted that Jf K : JXK ! JY K + Exc and that similarly Jtry ff g catch fTi ) gig1 i nK : JXK ! JY K + Exc. When n = 1 we get: Jtry ff g catch fT ) ggK = [ normal Y j [ JgK j abrupt Y ] untagT ] Jf K : This de nition matches that of Java exceptions [9, Ch. 14] or C++ exceptions [1, §15]. In particular, in the interpretation of try ff g catch fTi ) gig1 i n, each function JgiK may itself raise exceptions; and the types T1; : : : ; Tn need not be pairwise distinct, but if Ti = Tj for some i < j then gj is never executed. 5
In Sections 3 and 4 we have formalized the signature for exceptions Sig exc, its associated core signature Sig core , and we have described their denotational semantics. However the soundness property is not satis ed, in the sense that the denotational semantics is not a model of the signature, in the usual sense: indeed, a term f : X ! Y is not always interpreted as a function Jf K : JXK ! JY K; it may be interpreted as Jf K : JXK ! JY K + Exc, or as Jf K : JXK + Exc ! JY K + Exc. In order to get soundness, in this Section we add decorations to the signature for exceptions by classifying the operations and equations according to the interaction of their interpretations with the mechanism of exceptions.
Signature (Section 3) decoration / Decorated signature (sound) (Section 5) / Semantics (Section 4) interpretation 5.1
Decorations for exceptions
By looking at the interpretation (in Section 4) of the syntax for exceptions (from
Section 3), we get a classi cation of the operations and terms in three parts,
depending on their interaction with the exceptions mechanism. The terms are
decorated by (0), (
For instance, the decoration (0) corresponds to the decoration noexcept in C++
(replacement of the deprecated throw()) and the decoration (
The interpretation of these three kinds of terms and two kinds of equations is summarized in Fig. 4. It has been shown in Section 4.1 that any propagator can be seen as a catcher and that any pure term can be seen as a propagator and thus also as a catcher. This allows to compose terms of di erent nature, so that it is not a restriction to give the interpretation of the decorated equations only when both members are catchers.
X X X
X term f f f term term / Y / Y / Y
X X X
X pure term
f(0) propagator
f(
JXK X + Exc J K
JXK
JfK JfK
JfK f = g J K J K / Y
J K / JY K + Exc
/ JY K + Exc Jf K normal JXK = JgK normal X
J K
Now we can add decorations to the signature for exceptions Sig exc and its associated core signature Sig core , from De nitions 1 and 2.
De nition 10. The decorated signature for exceptions Sig edxecco and its associated decorated core signature Sig cdoerceo are made of Sig exc and Sig core , respectively, decorated as follows: the basic operations are pure, the tagging, raising and handling operations are propagators, and the untagging operations are catchers. 5.2
Decorated rules for exceptions
In this Section we de ne an equational proof system for exceptions. This proof
system is made of the rules in Fig. 5. It can be used for proving properties of
exceptions, for instance in the Coq proof assistant. In Fig. 5, the decoration
properties are often grouped with other properties: for instance, \f (
C1 Cp
Rules (a) are the usual rules for the monadic equational logic; they are valid for all decorated terms and for strong equations. Rules (b) provide more information on the decorated monadic equational logic for exceptions; in particular, the substitution of f in a weak equation g1 g2 holds only when f is pure, which is quite restrictive. Rules (c) ensure that the empty type is a kind of initial type with respect to weak equations. Rules (d) are used for case distinctions between exceptional arguments (on the \0" side of X + 0) and non-exceptional arguments (on the \X" side of X + 0). The symbol in rules (e) is interpreted as the downcast conversion, see De nition 5. Rules in (f) mean that the tagging operations are interpreted as the canonical inclusions of the exceptional types in the set Exc, see De nition 6. The rules in (g) determine the untagging operations up to strong equations: an untagging operation recovers the exception parameter whenever the exception type is matched, and it propagates the exception otherwise see De nition 8.
Remark 1. It has been shown in [3] that the denotational semantics of the core language for exceptions is dual to the denotational semantics for states: the tagging and untagging operations are respectively dual to the lookup and update operations. In fact, this duality is also valid for the decorated equational logics.
This decorated proof system is used now (in De nition 12) for constructing the raising and handling operations from the core tagging and untagging operations. It has to be noted that the term catch fTi ) gig1 i n f may catch exceptions, while the handling operation, which coincides with catch fTi ) gig1 i n f on non-exceptional values, must propagate exceptions; this is why the downcast operator is used.
ation throw T(1;)Y : T ! Y is the propagator de ned as:
throw T(1;)Y = [ ]Y
tagT :
De nition 12. For each propagator f (
untagTn
[gi j recover i+1 ] untagTi
when i = n;
when i < n:
Then, the handling operation (tryff g catch fTi ) gig1 i n)(
tryff g catch fTi ) gig1 i n = (catch fTi ) gig1 i n f ) When n = 1 we get: tryff g catch fT ) gg = (catch fT ) gg f ) = ([ id Y j g untagT ] f ): Now Theorem 1 derives easily, by induction, from Fig. 5 and 4 and from De nitions 11 and 12.
5.3
A decorated proof: a propagator propagates
With these tools, it is now possible to prove properties of programs involving
exceptions and to check these proofs in Coq. For instance, let us prove that
given an exception, a propagator will do nothing apart from propagating it.
Recall that the interpretation of [ ]Z (or, more precisely, of [ ]Z ) is abrupt Z :
Exc ! JZK + Exc. J K
Lemma 1. For each propagator g(
(c)1 (a)
X [ ]X : 0 ! X (c)2 (b)4 g [ ]X : 0 ! Y g [ ]X The proof in Coq follows the same line as the mathematical proof above. It goes as in Figure 6. The Coq library for exceptions, EXCEPTIONS-0.1.tar.gz, can be found online: http://coqe ects.forge.imag.fr (in le Proofs.v) with proofs of many other properties of programs involving exceptions.
It should be recalled that any Coq proof is read from bottom up. The application of the from empty is weakly unique rule certi es that the term g o (@empty X), because its domain is the empty type, is weakly equal to the term (@empty Y). Thus, we have the left side sub-proof: g o (@empty X) (@empty Y). There, weak equality is converted into strong: applying propagator weakeq is strongeq resolves the goal: g o (@empty X) == (@empty Y) and produces as sub-goals that there is no catcher involved in both hand sides (middle and right side sub-proofs).
forall X Y (g: term Y X), is propagator g -> g o (@empty X) == (@empty Y). Proof.
intros. (* (b)4 *) apply propagator weakeq is strongeq. (* (b)2 *) apply is comp. assumption. (* (b)1 *) apply is pure propagator. (* (c)3 *) apply is empty. (* (b)3 *) apply is pure propagator. (* (c)4 *) apply is empty. (* (c)2 *) apply from empty is weakly unique.
Qed.
JuntagT K JtagRK = 6
In object-oriented languages, exceptions are usually the objects of classes which are related by a hierarchy of subclasses. Our framework can be extended in this direction by introducing a hierarchy of exceptional types: the set T is endowed with a partial order _ called the subtyping relation, and the signature Sig base is extended with a cast operation castR;T : R ! T whenever R _ T . The interpretation of castR;T is a pure function JcastR;T K : JRK ! JT K, such that JcastT ;T K is the identity on JT K and when S _ R _ T then tJhcaesftSu;nTcKtio=n JJucansttaRg;TTKK : EJxccas!tS;JRTK.K +DeExncitsioantis8 ehsafsortoeabche emxocedpi tieodnaalstyfopleloRws:: (normal JT K JcastR;T K abrupt JT K JtagRK when R _ T otherwise : R T +Exc:
J K ! J K Exceptions are part of most modern programming languages and they are useful in computer algebra, typically for implementing dynamic evaluation. We have presented a new framework for formalizing the treatment of exceptions. These decorations form a bridge between the syntax and the denotational semantics by turning the syntax sound with respect to the semantics, without adding any explicit \type of exceptions" as a possible return type for the operations. The salient features of our approach are: { We provide rules for equational proofs on programs involving exceptions (Fig. 5) and an automatic process for interpreting these proofs (Fig. 4). { Decorating the equations allows to separate properties that are true only up to e ects (weak equations) from properties that are true even when e ects are considered (strong equations). { Moreover, the veri cation of the proofs can be done in two steps: in a rst step, decorations are dropped and the proof is checked syntactically; in a second step, the decorations are taken into account in order to prove properties involving computational e ects. { The distinction between the language for exceptions and its associated private core language (De nitions 1 and 2) allows to split the proofs in two successive parts; in addition, the private part can be directly dualized from the proofs on global states (relying on [3] and [4]). { A proof assistant can be used for checking the decorated proofs on exceptions. Indeed the decorated proof system for states, as described in [4] has been implemented in Coq [2] and dualized for exceptions (see http: //coqeffects.forge.imag.fr).
We have used the approach of decorated logic, which provides rules for computational e ects by adding decorations to usual rules for \pure" programs. This approach can be extended in order to deal with multivariate operations [5], conditionals, loops, and high-order functions.