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

Well had to think about this one for a little while; unfortunately because
these statements were simply so unproductive in the context of: regardless
of best intents, efforts, etc., programs, machines, etc. will and do "fail"
either quietly, detectable and recoverably, or otherwise, with varying
degrees of significance, for which there are no formal methods of design or
analysis to absolutely prevent; as such have simply observed that scheme
hasn't specified a mechanism to capture run-time language "errors" to enable
their attempted recovery (by user code, srfi's or otherwise) if and when
they do occur, implying that they implicitly, potentially catastrophically,
halt program execution if they were not foreseen as potentially occurring
and prevented by the programmer, or infallibly detectable though formal
methods (as previously cited, but would be very interested in any known
tool or method which claims otherwise).

Within this context, there seem to be two basic potential solutions:

1) within the programmers environment, outside of scheme's specification,
redefine every single scheme function, and syntax expression which may yield
an "error" to intercept and analyze it's argument which may otherwise yield
errors prior to there manifestation, and enable the program's temporary
escape to an error handling context which was specified by some previously
defined "catching" error handler; redefining (or possibly more accurately,
defining) scheme's error and user-defined exception handling semantics in
it's absents. (which could leverage the SRFI 34/35 or other architecture).

2) or to do the same, but incorporate it within scheme's specification; or
minimally enable it by possibly specifying that the main body of a program
is invoked within a top-level globally specified error handler which may be
hierarchically re-specified within successive lexical scopes, which will be
called via call/cc or similar mechanism, upon encountering a scheme defined
"error" or something like that. (rather than implying scheme "errors" halt
program execution).

Reasonable responses include:

- don't understand. or I believe that the world knows how to write error
  free programs; or that program halting upon an error is ok. (which is
  ok, but would be a loss as to how to try to make a further case for it.)

- understand, but believe it's beyond the scope of scheme's target market.

- understand, but believe it belongs within the user's domain to provision.

- understand, but believe that prior to incorporation of any new feature,
  it should be first implemented, and sufficiently experimented with to
  determine it's likely true value, and/or architecture, but have no opinion
  on how it possibly could/should be enabled.

- understood, seems like ... might be the way to specify/enable it.

or something like that; any brave and/or foolish soles out there?

-paul-


>"Bradd W. Szonye" <bradd+plt at szonye.com> writes:
>>>"Bradd W. Szonye" <bradd+plt at szonye.com> writes:
>>> If the program must not fail, then "soft" and "hard" failures are
>>> equally unacceptable.
> 
>> Joe Marshall wrote:
>> Agreed.  And it is far easier to build a robust system on top of a
>> fail-fast system than on top of a fail-slow one.
> 
> That's the common wisdom, and my experience agrees with it.