Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!comp.vuw.ac.nz!cc-server4.massey.ac.nz!E.Ireland
From: E.Ireland@massey.ac.nz (Evan Ireland)
Newsgroups: comp.lang.functional
Subject: Re: Implementing Error Values
Message-ID: <450sis-b@massey.ac.nz>
Date: 26 Nov 90 00:07:35 GMT
Reply-To: E.Ireland@massey.ac.nz
Organization: Information Sciences, Massey University, New Zealand
Lines: 84


> 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.

I don't have pointers to papers (some have already been posted), but I
have just started modifying a Lazy FAM (Functional Abstract Machine)
implementation for use with a Haskell compiler, and I was planning to
replace the ML-style exception handling operations with error values,
because ML-style exception handling seems inappropriate for lazy
languages.

Haskell as it stands has no exception handling or error values, but I
think I may find use for error values within the implementation, even
if they are not directly manipulable by the language.  This
implementation uses header/tag fields in all heap objects, so error
values simply require reserving another tag value.  I intend to have
polymorphic, parameterised, error values, so that I can have
Error "divide by zero", Error "unexpected case" etc.

The other idea I have been tinkering with is allowing pattern-matching

    factorial n | n < 0 = Error "factorial of negative number"
    -- I won't bother you with the other cases!
    
    f e@(Error _) = 0
    f 0 = 1
    f n = 2

    isError (Error _) = True
    isError _         = False


> The only problem I could see with the scheme (and didn't have time to
> investigate) was that normally complete pattern matches (such as nil vs.
> hd :: tl) were no longer so, and it wasn't clear that termination of
> sensible functions could be guaranteed (a length-of-list function called
> with an error value would probably loop indefinitely, for example...)

My idea for solving this problem is to specify that any pattern-match
that doesn't specify an error alternative has an error alternative
implicitly introduced.  Function definitions and conditionals would be

    length []     = 0
    length (_:xs) = 1 + length xs


    length l = case l of
		 []     -> 0
		 (_:xs) -> 1 + length xs


    length l = case l of
		 e@(Error _) -> e		-- propagate error
		 []          -> 0
		 (_:xs)      -> 1 + length xs

If the length function had been written using a predicate and selector
functions, we would expect a similar result (as long as the `null'
predicate returns an error value when given an error value as
argument).

    length l = if null l then 0
	       else 1 + length (tail l)


    length l = case null l of
		 True  -> 0
		 False -> 1 + length (tail l)


    length l = case null l of
		 e@(Error _) -> e		-- propagate error
		 True        -> 0
		 False       -> 1 + length (tail l)

Please forgive me if this is all old hat.  I haven't chased up any of
the references yet so I don't know how much of this has been covered
before.  Still I hope it is useful to someone (Patrick in particular)!

				  Evan Ireland (E.Ireland@massey.ac.nz),
School of Information Sciences, Massey University, Palmerston North, NZ.