Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.functional
Subject: Re: BOTTOM !== NONTERMINATION
Message-ID: <23552@megaron.cs.arizona.edu>
Date: 26 Jul 90 19:25:40 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 33

In article  <3936@rex.cs.tulane.edu> fs@rex.cs.tulane.edu (Frank Silbermann) writes:
]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.

Hmm.  Well, I'd have to say that bottom _is_ synonymous with
nontermination if the only programs that are defined to represent
bottom are those whose evaluation will never terminate.  This is the
case in the lambda calculus, for example.  And yes, such a statment
is relative to the method of evaluation.

It is important to distinguish between semantics and operations, but
lets not fall into the trap of thinking that it's "impure" or "dirty"
to discuss operations and semantics at the same time.  When discussing
optimization you _have_ to discuss semantics and operation at the same
time.  Both are involved in the specification of the problem.

This does bring up a point though.  It might be a good idea _not_ to
limit the idea of bottom and let it include more general undefined
operations such as out-of-range references and whatever peculiar
things might result from that.  In this case, it would be allowable
for some program optimizations to change an error result into bottom.
For example an optimization that removes bounds checking from array
references might be allowed even though it has the potential of
changing an error result into practically anything.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman