Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!bu.edu!m2c!risky.ecs.umass.edu!dime!yodaiken
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.lang.misc
Subject: Re: definitions
Message-ID: <29865@dime.cs.umass.edu>
Date: 29 Apr 91 20:21:58 GMT
References: <2494@optima.cs.arizona.edu> <51984@nigel.ee.udel.edu> <333124@socrates.umd.edu> <52164@nigel.ee.udel.edu>
Sender: news@dime.cs.umass.edu
Reply-To: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Organization: University of Massachusetts, Amherst
Lines: 19

In article <52164@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
>Excuse me?  Any language implementing while loops has functions which
>won't terminate, strong typing or not.  Or do you mean it will terminate

Not necessarily. Only if we allow "types" that are not well-founded.
And, why we would want to do that in a computer programming language
is beyond me.

>My point is that if you have an exception-handling mechanism that
>the programmer can use to catch "message not understood" errors, then
>one cannot really say that the behavior of a function generating a
>message-not-understood is "undefined".  Something that aborts the
>program without giving the program a chance to clean up could be
>considered a runtime error.  Undetected errors are also "errors".
>

Not undefined, but not well defined. i.e. f(x) = { g(x) or unroll
                                                   program state ...}
Not very nice.