[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue EXIT-EXTENT-AND-CONDITION-SYSTEM Writeup

Issue:              EXIT-EXTENT-AND-CONDITION-SYSTEM

References: CATCH, THROW, UNWIND-PROTECT,

HANDLER-BIND, RESTART-BIND

Related issues: EXIT-EXTENT

Category: CLARIFICATION

Edit history: v1, 22 Feb 1991, Sandra Loosemore

v2, 11 Mar 1991, Sandra Loosemore

Problem description:

The EXIT-EXTENT issue doesn't specify how exit points interact with

the dynamic bindings of condition handlers and restarts. At what

point in the execution of non-local transfers of control do the

extents of handlers and restarts established by HANDLER-BIND and

RESTART-BIND end?

Proposal (EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS):

Clarify that undoing of handler and restart bindings during an exit

happens in parallel with the undoing of the bindings of special variables

and CATCH tags, in the reverse order in which they were established.

The effect of this is that the cleanup clauses of an UNWIND-PROTECT

will see the same handler and restart bindings, as well as dynamic bindings

and CATCH tags, as were visible with the UNWIND-PROTECT was entered.

Examples:

???

Rationale:

Presumably many implementations use dynamic bindings and CATCH to

implement handler and restart bindings.

Current Practice:

The sample condition system implementation uses dynamic bindings and

CATCH to implement handler and restart bindings.

Cost to Implementors:

Probably none.

Cost to Users:

Probably none.

Cost of non-adoption:

Continuing vagueness in the language specification.

Performance impact:

Probably none.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

Being consistent with issue EXIT-EXTENT is a good thing. Whether

issue EXIT-EXTENT was resolved in an esthetic manner is another

question.

Discussion:

This issue was raised by Barry Margolin on the X3J13 mailing list.

Kim Barrett notes:

A consequence of this proposal is that

(catch 'foo

(handler-case

(unwind-protect

(throw 'foo nil)

(error "foo"))

(error () (print 'foo))))

has undefined consequences. This is why I voted against EXIT-EXTENT. Of

course, few people listened then so why should they listen now.

Moon replies:

....[this] is a consequence of EXIT-EXTENT and has

nothing to do with EXIT-EXTENT-AND-CONDITION-SYSTEM, which speaks

only of when bindings are disestablished, not when using those

bindings becomes undefined, which is the subject of EXIT-EXTENT.

EXIT-EXTENT-AND-CONDITION-SYSTEM tells us that the handler binding

extablished by the HANDLER-CASE becomes disestablished when control

passes outside the HANDLER-CASE and not before. In particular this

binding is still established while the UNWIND-PROTECT cleanup form

is executing. It is difficult to imagine what other semantics

for this part could be defensible.

EXIT-EXTENT tells us that the exit point used by the handler established

by the HANDLER-CASE cannot be used after the THROW commences. Note that

this is not the same binding as the one discussed by

EXIT-EXTENT-AND-CONDITION-SYSTEM. It is certainly possible to imagine

other defensible semantics for this part, we spent years discussing it.

JonL says:

I can think of few things more horrible than re-opening the issue

of EXIT-EXTENT.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.