[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
- To: email@example.com
- Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
- From: gls@Think.COM
- Date: Tue, 24 May 88 10:43:34 EDT
- Cc: firstname.lastname@example.org, email@example.com
- 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 <firstname.lastname@example.org>
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.
(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
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?