Hello John!
On 8/3/20 6:41 AM, John Cowan wrote: > > > On Sun, Aug 2, 2020 at 2:05 PM Zelphir Kaltstahl > <[email protected] <mailto:[email protected]>> wrote: > > > 1. Is there any situation, in which one would like to raise a > non-continuable exception / condition, and not unwind the stack? Would > that make sense in any situation? > > > I'm going to talk about Scheme in general, not Guile specifically. > There are at least three use cases: > > 1) A reflective low-level debugger that can examine variables in the > current stack frame, which can't possibly work if the stack frame is gone. > > 2) A handler that wants to examine the dynamic environment in place > when the exception was raised. > > 3) A restart system that returns to the context of the raise and > executes recovery code, often chosen on the basis of interaction. > Frequently used recovery actions include retrying the failed operation > (on the assumption that the external environment has changed), > retrying the operation with one or more different variables, and > setting local variables to new values and retrying. > > A "Lisp debugger" is code that examines the available restarts and > invokes one of them, but Scheme doesn't have such a thing yet because > it has no restart system yet. See > <https://github.com/johnwcowan/r7rs-work/blob/master/RestartsCowan.md>. > CL has a restart system rather more complex than my proposal, which is > based on an earlier proposal by Taylor Campbell. > > > Is this all correct? > > > I would say "correct but not complete". > > > 3. What would be a code example for a continuable exception / > condition > and what does the "continuing" there look like? I think the idea of > exception in my head is still influenced a lot by Python or other > languages, where it seems like all exceptions are non-continuable. (Is > that correct?) > > > Let's say a procedure wants to open a configuration file, but the > configuration file cannot be opened. Raising a continuable exception > allows the handler to take some recovery action (perhaps it prompts > the user for the location of the config file) and return to the point > where the exception was raised. Restarts extend this concept by > providing a protocol for the handler to communicate with the raiser, > just as condition objects are a protocol to let the raiser communicate > with the handler. > > In languages without continuable exceptions, such a retry must be done > from the handler level, which may imply re-executing a lot of code > that was run before the config file was wanted. With continuable > exceptions, this is not necessary. > > The `guard` special form basically emulates the behavior of {Python, > JS, Java, C#} style exception systems in cases where that behavior is > sufficient. > > > 4. Is there a situation, where one would like to raise a continuable > exception / condition, but also unwind the stack? > > > Not that I can think of. > > > IWhat does it mean for with-exception-handler to "return"? How can > it not > return? Does this mean CPS like not returning, or does it mean "not > return a value"? > > > The former. An exception being raised non-continuably is really > raised continuably, but then if that returns, an exception that means > "attempt to continue from a non-continuable exception" is raised > non-continuably. If you aren't careful in your handler to re-raise > exceptions you don't understand (normally with raise-continuable), > this will obviously get into an infinite loop. > > (In CL the behavior of a handler is slightly different. If it > returns, the exception is re-raised automatically. so in order to > unwind the stack one must use one of CL's three upward continuations: > block/return, tagbody/go, or catch/throw. The last is dynamically > scoped, so it is usually the thing to do in this context. > Handler-bind, like guard, is a convenience macro for emulating > stack-unwonding systems._ > > > > John Cowan http://vrici.lojban.org/~cowan > [email protected] <mailto:[email protected]> > He that would foil me must use such weapons as I do, for I have not > fed my readers with straw, neither will I be confuted with stubble. > --Thomas Vaughan (1650) > Thank you for the examples! They explain, why one would want to have the flexibility to decide whether to unwind or not to unwind. I'll try to perhaps add a phrase like "There are some scenarios, in which not unwinding makes sense, for example …". I'm glad, that my understanding was not completely wrong. Regards, Zelphir
