[plt-scheme] to define, or to let (new twist)

Paul Schlie wrote:
> My point should likely have been that scheme needs a recoverable
> exception mechanism to enable it's use in applications which must not
> "halt" ....

OK. I see now that you were responding to a different subthread. There
wasn't enough context in your earlier message to figure that out, and it
threaded in a strange place.

> - a program comprehensively covers as desired the entire encountered
>   (not just anticipated) range and domain of its reachable state/data space.
> 
>    -> no errors, no problems.

Are you talking about the program as designed or the program as
implemented? If the program never encounters an error, that's good, but
unless you can prove that it can't possibly encounter an error, you'll
need to plan for the following two cases.

> - a program reaches an unanticipated state, due to unanticipated data,
>   and/or erroneous program code.

This situation is simply unacceptable in a program which must not halt.
Not much you can say about it beyond that. If it's an embedded but
non-critical app, you can halt, reset, and restart the system. You're
pretty much screwed if it's a life-critical system.

>   -> data/state is still within the domain of the specified behavior
>      of the code; no error, keeps running, although results may not be as
>      intended.
>
>   -> data/state is outside the domain of the specified behavior of the code,
>      error; program stops, whatever the program may have been doing (like
>      controlling the cooling of a reactor core, it's not doing any longer,
>      potentially catastrophic).

I don't see much practical difference between these two cases, if the
program truly must not fail. What good is it to keep the program running
after you've detected an inconsistent program state or similar "panic"
error? While the program may not "halt," it isn't doing what it's
supposed to anymore, either. You can easily end up situations like the
Ariane catastrophe, where the incorrect data sets up a positive feedback
loop.

If the program must not fail, then "soft" and "hard" failures are
equally unacceptable.

If it's OK for the program to fail, then one must consider other factors
before choosing a soft or hard failure. Soft failures are generally
better for interactive applications, so long as it's not a "panic"
failure. Hard failures are generally better (IME) for debugging, batch
programs, and panics.

> So maybe it would be more generally correct to observe that a
> recoverable exception architecture possibly similar to MzScheme's
> should considered for R6RS ....

There is no general way to handle exceptional situations. One really
must consider the nature of the program and the nature of the exception.
Exception-handling is an important element of program design, and there
is no generally-useful "default" IMO.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd