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

My point should likely have been that scheme needs a recoverable exception
mechanism to enable it's use in applications which must not "halt"; rather
than attempting to propose a sloppy half baked potential solution be
pondered, in a poor attempt to change topics of discussion.

However if:

- 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.

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

  -> 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).

    (or with some from of error interception/recovery)

     data/state is outside the domain of the specified behavior of the code,
     error; program is enabled to try to recover, but doesn't seem to be
     presently accomplishable within the specification of scheme's error
     semantics. (or maybe it is, as it's not really specified what happens
     when an error occurs; however unless an evaluation of a function which
     results in an error is enabled to return a value somehow, the program
     will implicitly terminate, which is not good if otherwise desired.)

So maybe it would be more generally correct to observe that a recoverable
exception architecture possibly similar to MzScheme's should considered for
R6RS; to enable the specification of recoverable exceptions within scheme
macro and function definitions, as would be necessary to enable the
specification of a program capable of dynamic run-time error recovery, in
lieu of halting.

-paul-

> Bradd W. Szonye wrote:
>
> Whoah! First you need to back up your premise about halted programs. A
> program that keeps running in the presence of errors is much more likely
> to corrupt data than one which merely halts, and corrupted data is an
> especially nasty form of catastrophic failure.
>
> Also, I don't particularly see what this has to do with the discussion
> so far, nor do I believe that it's possible to define "innocuous"
> behavior for major contract violations in function calls (like your
> (+ <void>) example).