Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!rex!fs
From: fs@rex.cs.tulane.edu (Frank Silbermann)
Newsgroups: comp.lang.functional
Subject: Re: Can laziness sometimes be too lazy?
Message-ID: <3926@rex.cs.tulane.edu>
Date: 25 Jul 90 12:02:55 GMT
References: <2706@bruce.cs.monash.OZ.AU> <3188@osc.COM>
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Lines: 24

In article <3188@osc.COM> jgk@osc.COM (Joe Keane) writes:
>
>	Suppose we're in a language with real exception handling.
>	It's only a matter of terminology whether you count an exception
>	as a kind of return value, a side effect, or something different.

>	In particular, defining errors to be the same as bottom
>	is an unwise thing to do ...

If you "handle" an exception then it is no longer an error
-- just another possible result.  Semantically speaking,
an error is an _unhandled_ exception.  Since it is unhandled,
why not declare the result to be `undefined' (i.e. is bottom)?

Make an analogy with mathamatics.  Consider the function f(x) = 5/x.
What is the value of the function at x=0?  `Error' or `undefined'?

It is a design issue as to whether you make the programmer
handle exceptions explicitly, or whether the language implicitly
tacks on exception-handling routines.  I have no argument
with those who advocate implicit exception-handling mechanisms
(though the increased expressiveness requires a more complicated language).

	Frank Silbermann	fs@rex.cs.tulane.edu