Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!sdd.hp.com!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!newcastle.ac.uk!turing!ndah
From: D.A.Harrison@newcastle.ac.uk (Dave Harrison)
Newsgroups: comp.lang.functional
Subject: Re: Implementing Error Values
Keywords: pointers, papers, paraphernalia, error values, implementation
Message-ID: <1990Nov24.121432.29282@newcastle.ac.uk>
Date: 24 Nov 90 12:14:32 GMT
References: <86438@lll-winken.LLNL.GOV>
Sender: news@newcastle.ac.uk
Followup-To: comp.lang.functional
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU.
Lines: 79

In article <86438@lll-winken.LLNL.GOV>, miller@lll-crg.llnl.gov (Patrick
Miller) writes:
>I'm looking for pointers to papers about implementing error values in
>functional languages (or other styles).  By error values, I mean that
>the value of a calculation is replaced by a placeholder denoting the
>error.  This allows some form of error handling without invoking the
>concept of global state.

As other posters have pointed out this is a fairly simple thing to do. More
complicated is to handle the propagation of exceptions in a lazy functional
language.

A while ago I was one of the authors of a couple of papers on exception 
handling in lazy functional languages [2, 3]. Our major interest was to handle
(the propagation of) exceptions in a way that preserved lazy semantics and 
commutativity of operators.

i.e. we wanted 

	hd (x : exception) <=> hd (x : ~exception)

and

	exception1 + exception2 <=> exception2 + exception1

exception, exception1 and exception2 are arbitrarily complex expressions whose 
evaluation causes the raising of exceptions. exception1 and exception2 raise
two different exceptions.

We based the work on the failure sets model of [4] which was first (as far as
I know) applied to functional languages in [1].

Although we mangaged to achieve the aim of preserving lazy semantics and
commutativity we had to restrict the power of the exception signalling,
propagation and handling mechanism so much that what we ended up with could be 
expressed relatively straight forwardly in a lazy functional language such as 
Miranda. In fact, as far as I remember, we actually wrote the Miranda functions
required.

I have doubts that an alternative approach would do any better, though
obviously I can't prove it. My belief is that it is more or less impossible to 
produce an exception mechanism that significantly enhances the
expressive power of a language without losing "normal" lazy evaluation 
semantics.

Dave

[1] "An exception handling construct for functional languages"
    M. Bretz & J. Ebert
    Proceedings ESOP88, 2nd Europeand Symposium on Programming,
    Spriger-Verlag LNCS 300

[2] "Gerald : An exceptional lazy functional programming language"
    A.C. Reeves, D.A. Harrison, A.F. Sinclair, P. Williamson
    Functional Programming: Proceedings of the 1989 Glasgow Workshop,
    21-23 August 1989, Fraserburgh Scotland.
    Eds: K. Davis and J. Hughes.
    Springer Workshops in Computing 1990

[3] "How to make a lazy functional language exceptional"
    A.C. Reeves, D.A. Harrison, A.F. Sinclair, P. Williamson
    Proceedings TENCON '89 (IEEE Region 10 conference) on Functional
    Programming Languages : Theory & Applications
    Bombay November 1989

[4] "An axiomatic treatment of exception handling in an expression-oriented
    langauge"
    S. Yemini & D.M. Berry
    ACM TOPLAS Vol 9, NO 3 1987

---------------------------------

Dave Harrison				JANET: D.A.Harrison@uk.ac.newcastle
Computing Laboratory			PHONE: +44 91 222 7784
University of Newcastle upon Tyne
Newcastle upon Tyne NE1 7RU
U.K.

	"A proton is the same as a neutron, only coloured in differently."