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: BOTTOM !== NONTERMINATION
Keywords: bottom, exception handling
Message-ID: <3973@rex.cs.tulane.edu>
Date: 5 Aug 90 02:43:39 GMT
References: <3936@rex.cs.tulane.edu> <3940@rex.cs.tulane.edu> <3207@osc.COM>
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Lines: 40


>>		(... if an interpreter detects blatant infinite loops ...)
>>		Must the result be considered as a different language,
>>		just because the interpreter is _sometimes_ able to tell you
>>		that the program denotes bottom, instead of just looping?
>>
>>		As long as the program is forbidden to make use of
>>		the extra metalogical information,
>>		it need not be considered a change in the language.
>>		So bottom need not imply nontermination.

In article <3207@osc.COM> jgk@osc.COM (Joe Keane) writes:
>	Granted, if the extra information is not available
>	to user programs, then it's not part of the language.
>	My question is, why would you want to do this?

It's all a matter of perspective.  When I run my C programs
under a debugger, I _could_ consider myself to be using
a new language -- the error behavior _is_ different.
But I prefer to consider the language and the debugging environment
as two distinct parts of the system.

When the interpreter stops my program upon seeing `cdr(5)'
and tells me what line of the program it was executing,
it seems clear to me that this is metalogical information.
The program cannot be aware of its own line numbers
and still maintain _referential transparancy_.
Yet, I find this information critically useful in debugging.

Therefore, I consider statements such as `cdr(5)'
to be undefined (bottom) in the semantics,
and I view error messages as being the output
of a rudimentary debugger which my translator invokes by default.
By separating the error messages from the semantics,
I can view programs in certain languages as being
composed of mathematical assertions -- and to me
this is what _functional programming_ is all about.

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