Subject: Re: newbie: non local exits in CL From: Erik Naggum <erik@naggum.no> Date: 1997/07/12 Newsgroups: comp.lang.lisp Message-ID: <3077688988077169@naggum.no> * Kent M. Pitman | Right. In fact, since UNWIND-PROTECT was also mentioned, ... | It is ALMOST ALWAYS better to simply write: | | (let ((old-value (figure-out-some-state))) | (unwind-protect (...whatever...) | (restore-state old-value))) sorry for butchering a fine article, but I have discovered something I found to be quite hard to do in a reasonable manner. I first saw it in Emacs Lisp, which can become quite seriously confused if you interrupt it in the middle of some cleanup-forms that take non-zero time to complete. Common Lisp the Standard reads: # `unwind-protect' evaluates protected-form and guarantees that # cleanup-forms are executed before `unwind-protect' exits, whether it # terminates normally or is aborted by a control transfer of some kind. # `unwind-protect' is intended to be used to make sure that certain side # effects take place after the evaluation of protected-form. if some interrupt can occur at any time in the protected-forms, it stands to reason that it might as well occur in the cleanup-forms, especially if it's a user hitting an interrupt key repeatedly. in Emacs, I experimented with delaying quits (Emacs' name for handling a user's C-g) until after the cleanup-forms had terminated, but it had the nasty side effect of making Emacs uninterruptible in several cases. so, how strong is the wording "guarantees that cleanup-forms are executed before `unwind-protect' exits", considering that it is left open _how_ the `unwind-protect' is exited, presuming that it could also be exited non-locally? under Unix, good programmers have become used to wrap critical code in a whole lot of silly tests for error returns form everything under the sun, but they still need a way to guarantee that a sequence of operations has been completed before some other operation is started, and they have the ability to belay all signals during critical regions. even though this is Unix-centric, I imagine there must have been a way to obtain a similar guarantee of completed sequences of operations even in the absence of an ill-designed error return policy like Unix'. (I don't know much about real-time programming, but it appears to me that such a question would have had to be asked and answered in real-time systems.) #\Erik -- if DUI is "Driving Under the Influence" then GUI must be "Graphics Under the Influence"