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

no, both runtime; simply meant that there are occasions when it would be
nice to be able to intercept "errors", and initiate an alternative action;
rather than have to recode routines to detect the condition prior to it's
effect. Personally I don't perceive initiating conscious alternative actions
are akin to ignoring errors, as I know there are many circumstances when
there are good alternatives to "failure".

(as a simple example, digital signal processing routines typically benefit
 from non-strict adherence to numerical rules; as it is often better (more
 graceful, with less significant discontinuities), to approximate a divide
 by zero, or overflow, etc, by their closest valid representations although
 not literally correct, are often better than typically defined language
 semantics; and am confident that non-numerical analogies exist in various
 forms in arbitrary programs; for which scheme provides no convenient way to
 intercept, other than apriority, which can tend to be very inefficient)

likely not a big deal for some, although significant to others, all depends.

-paul-

> From: Joe Marshall <jrm at ccs.neu.edu>
> Date: Mon, 29 Mar 2004 09:10:26 -0500
> To: Paul Schlie <schlie at comcast.net>
> Cc: <plt-scheme at list.cs.brown.edu>
> Subject: Re: [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.
>