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

Paul Schlie <schlie at comcast.net> writes:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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).

This is essentially static typing.

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

I think that halting upon an error is a fine thing.  It is a step
forward from the usual C solution of ignoring the error as long as
possible.

In the case of asynchronous errors, I have heard that aborting and
restarting is quite effective.