🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.lang.functional
1 messages
1 total messages Started by Evan Ireland Mon, 26 Nov 1990 00:07
Re: Implementing Error Values
#526
Author: Evan Ireland
Date: Mon, 26 Nov 1990 00:07
84 lines
3565 bytes
> 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.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads