Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!mimsy!jogger.cs.umd.edu!straub
From: straub@jogger.cs.umd.edu (Pablo A. Straub)
Newsgroups: comp.lang.functional
Subject: Re: Implementing Error Values
Keywords: pointers, papers, paraphernalia, error values, implementation
Message-ID: <28380@mimsy.umd.edu>
Date: 7 Dec 90 15:57:28 GMT
References: <86438@lll-winken.LLNL.GOV> <1990Nov24.121432.29282@newcastle.ac.uk> <4043@osc.COM> <1990Dec6.205610.1022@lescsse.uucp>
Sender: news@mimsy.umd.edu
Reply-To: straub@jogger.cs.umd.edu (Pablo A. Straub)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 20

In article <1990Dec6.205610.1022@lescsse.uucp> dnsurber@lescsse.uucp (Douglas Surber) writes:
   . . .
  Assume that exceptions are added to the domain just above bottom and that they
  are indistinguishable from bottom except by a special function catch
   . . . [several examples and ideas]
     E3
     WHERE
         E3 = ... [expression with a divide by zero and an infinite recursion]
  
  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.

I see nothing wrong with collecting all errors: it preserves determinism.
If exceptions are really exceptional there is little waste.  The value of
E3 above is indeed bottom (you should not expect your exception handling
mechanism to help you with the halting problem).

Pablo Straub