[plt-scheme] R6RS exception handling and dynamic extent [was: SXML for R6RS]

On Thu, 2008-07-10 at 09:28 -0600, Matthew Flatt wrote:
> At Thu, 10 Jul 2008 10:11:41 -0500, "Robby Findler" wrote:
> > On Thu, Jul 10, 2008 at 10:08 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > > At Thu, 10 Jul 2008 10:00:42 -0500, "Robby Findler" wrote:
> > >> I think I'm missing some earlier important part of this conversation
> > >> and I wonder if it could be said again for others who might be like
> > >> me?
> > >>
> > >> Why is guard causing problems (when combined with continuable
> > >> exceptions, etc)?
> > >
> > > Both `guard' and `with-handlers' jump out to the dynamic extent of the
> > > `guard' or `with-handlers' form to check whether they want to handle a
> > > given exception. At that point, if the right way to handle the
> > > exception was to continue without jumps, then it's too late.
> > >
> > > As specified by R6RS, `guard' will at least jump back in to try further
> > > handlers --- but that facet of `guard' isn't in our implementation.
> > 
> > Oh, right, I see.
> > 
> > Would it be possible to have guard just not jump out, 
> 
> It should jump out for the same reasons as `with-handlers', right?

What are those reasons?  I've never known.  It's seemed bad to me that
every nested `guard' jumps out and back in for every re-raise because
that will screw with dynamic-wind befores and afters.  (My understanding
is that `with-handlers' never jumps back in and doesn't allow
continuing.)

> 
> > and for
> > with-handlers to either signal an error or not handle continuable
> > exceptions or something like that?
> 
> Yes, if you do that for `guard', too, then it avoids the problem.
> That's essentially un-merging the mechanisms for continuable and
> non-continuable exceptions (or at least un-merging them enough).

Since `guard' is described in the R6RS as re-raising using `raise', it's
not possible for the next handler to return to the original
`raise-continuable'.  I've been wondering if this was a mistake and not
the intent of the R6RS because it looks like the description of `guard'
was copied from SRFI-34, and SRFI-34 does not have `raise-continuable'
nor the notion of continuable exceptions, but maybe re-raising possibly
continuable exceptions using `raise' is intentional so that `guard'
prevents continuing back to the original `raise-continuable' since
`guard' has screwed with the dynamic-wind befores and afters?  But it's
still screwed with them, which just seems bad...

-- 
: Derick
----------------------------------------------------------------