#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.