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.