[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
- To: edsel!jonl@labrea.stanford.edu
- Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
- From: gls@Think.COM
- Date: Tue, 24 May 88 10:43:34 EDT
- Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
- In-reply-to: Jon L White's message of Tue, 24 May 88 03:00:59 PDT <8805241000.AA04953@bhopal.lucid.com>
Date: Tue, 24 May 88 03:00:59 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
...
What's not OK is to block a "committed" THROW. Without this restriction,
for example, an "abort" to top-level while runnining the application evaluator
noted below would never succeed; the THROW to FOO from within the cleanup
form would serve as an effect barrier such that no throw can go past it.
(loop
(catch 'foo
(unwind-protect
(Run-application-evaluator)
(throw 'foo t))))
...
But the very fact that you can run an arbitrary computation implies that
you can effectively block a THROW. For example, I can rewrite the loop
shown above as:
(labels ((again () (unwind-protect
(Run-application-evaluator)
(again))))
(again))
Admittedly this is likely to cause net stack growth in any implementation
I can think of, but semantically it is equivalent.
Another point: what good is signalling an error? It will give handlers a
chance to run, but is the error allowed to break out without invoking the
cleanup forms anyway?
--Guy