Path: utzoo!attcan!uunet!decwrl!sdd.hp.com!samsung!rex!fs
From: fs@rex.cs.tulane.edu (Frank Silbermann)
Newsgroups: comp.lang.functional
Subject: BOTTOM !== NONTERMINATION
Keywords: Domains as information systems, bottom, error
Message-ID: <3936@rex.cs.tulane.edu>
Date: 26 Jul 90 16:36:56 GMT
References: <3188@osc.COM> <3926@rex.cs.tulane.edu> <10268@brazos.Rice.edu>
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Lines: 48


David Gudeman:
> ...	Bottom is _not_ an error result,
>	so a program transformation is not allowed
>	to change a terminating program into a non-terminating program.

To refute a common assumption, I must say:

	_Bottom_ is NOT synonymous with nontermination!!!!

We are dealing with a DECLARATIVE paradigm,
and nontermination is an _operational_ concept.

BOTTOM simply means "undefined" -- nothing more.
Nontermination is just one possible way for this to happen.
The language designer is free to interpret
any syntax he pleases as being undefined.

Joe Keane:
>	I think the question is whether a list
>	should be allowed to have elements which raise exceptions.

This is a matter of taste, and "chacun a son gout."
It does seem inconsistent, however, to permit
_functions_ which raise exceptions on certain arguments,
but to forbid _lists_ from raising exceptions on certain elements.

Ramarao Kanneganti:
>	Error is more informative than bottom.
>	Would you equate abort(5) with bottom,
>	simply because abort is unhandled?

But it _is_ handled, at least to the extent of returning
an error code.  If you want your system to return error codes,
then a _complete_ denotational semantics would put error codes
into the domain.  This done, an error code is no different,
in principle, from any other atomic value.
If you want its occurrance to halt computation,
then operations must be strict, so as to detect and propagate the error.
If you want a lazy language, you can compute lazy lists
which may contain error codes as list-members.

>	But, if you want to give maximal information, it should be error.

Maximal information should not be confused with metalogical information.

	Frank Silbermann	fs@rex.cs.tulane.edu
	Tulane University	New Orleans, Louisianna  USA