Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!lescsse!dnsurber
From: dnsurber@lescsse.uucp (Douglas Surber)
Newsgroups: comp.lang.functional
Subject: Re: Implementing Error Values
Keywords: pointers, papers, paraphernalia, error values, implementation
Message-ID: <1990Dec6.205610.1022@lescsse.uucp>
Date: 6 Dec 90 20:56:10 GMT
References: <86438@lll-winken.LLNL.GOV> <1990Nov24.121432.29282@newcastle.ac.uk> <4043@osc.COM>
Organization: Lockheed Engineering and Sciences
Lines: 89

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

>Yikes, i have to disagree with that last statement.  I'd be interested in
>seeing a quick description of the major problems between exception handling
>and lazy evaluation.

Well, here goes. . .

Assume that exceptions are added to the domain just above bottom and that they
are indistinguishable from bottom except by a special function catch

	catch h e
	 = "if val is an exception" -> h "the info encoded in the exception"
	   val
	   WHERE
	       val = e

so that h is a handler and e is an expression.  Then if the evaluation of e
yields an exception, the value of catch is h applied the whatever info is
part of the exception, otherwise the value of catch is the value of e.

Now consider the following

    E1
    WHERE
	E1 = catch h ( (3/0) + (ln 0) )
	h "log of zero"    = 1
	h "divide by zero" = 0

The value of E1 seems to depend on the order of evaluation of the arguments
to the addition.  If the left operand is evaluated first, then the value of 
E1 is 0;  if the right operand is evaluated first then the value of E1 is 1.
This is bad.

In order to fix this we assume that even after generating an exception,
the evaluator presses on collecting exceptions until it has evaluated every
strict argument and that the order in which exceptions are raised is ignored.
Then we have the following:

    E2
    WHERE
	E2 = catch h ( (3/0) + (ln 0) )
	h "divide by zero, log of zero" = 2
	h "log of zero"    = 1
	h "divide by zero" = 0

Now the value of E2 does not depend on the order of evaluation of the operands
but the evaluator is required to press on with the evaluation of an expression
even after it has encountered and exception.  This seems wasteful.

   E3
   WHERE
       E3 = catch H ( (3/x) + (f x) )
       x = 0
       f 1 = 1
       f n = (f (n-1)) * n
       h "divide by zero, log of zero" = 2
       h "log of zero"    = 1
       h "divide by zero" = 0

The value of E3 is bottom.  Even though the evaluator has determined that
there is at least one error present, it must press on until it finds a really
bad error, that is bottom.  This does not seem like a good property for an
exception handling mechanism.

Summary:

Either the evaluator must continue to evaluate as long as possible, collecting
errors until it has evaluated all of the strict args of a function or it hits
bottom, or there will be order dependencies introduced.  Order dependencies 
complicate the semantics and/or reduce the utility of the language.

Clearly this is a superficial explaination of the problem, but it raises
the major issues as I understand them.

-- 
Douglas Surber                 Internet: lobster!lescsse!dnsurber@menudo.uh.edu
Lockheed (LESC)                UUCP:     lobster!lescsse!dnsurber
SSE SSFP                       NASAmail: dnsurber/jsc/nasa
Houston, Texas                 Phone:    713-283-5195

-- 
Douglas Surber                 Internet: lobster!lescsse!dnsurber@menudo.uh.edu
Lockheed (LESC)                UUCP:     lobster!lescsse!dnsurber
SSE SSFP                       NASAmail: dnsurber/jsc/nasa
Houston, Texas                 Phone:    713-283-5195