[plt-scheme] SXML for R6RS [was: R6RS Interoperability]

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Tue Jul 8 14:19:25 EDT 2008

At Thu, 03 Jul 2008 03:43:02 -0700, Derick Eddington wrote:
> * SSAX issue: MzScheme does not conform [1] to the R6RS expectation that
> the initial/default exception handler return for non-&serious
> conditions [2].  Returning for non-&serious conditions allows you to do
> things like raise-continuable a &warning condition to let interested
> clients catch it and do something about it and maybe return, or the
> default handler will return, and execution can continue.  I made my
> ssax:warn procedure do this and the SSAX library frequently
> calls ssax:warn when issues that often can safely be ignored happen. 

I worry about this implementation of `ssax:warn'. If someone calls into
SSAX with a context like

  (guard (exn
	  [(serious? exn) "give up"])
    (with-input-from-file
      "foo"
      (lambda ()
         ... call SSAX ...)))

then `ssax:warn' will lead to undefined behavior on the "foo" port when
control escapes to the `guard', even though the exception won't be
caught by the `guard' handler --- right? (I have in mind R6RS semantics
of exceptions and `guard', as opposed to the current PLT approximation.)


> I
> hacked together a patch to MzScheme so its default R6RS handler returns
> for non-&serious, though I'm not sure it meshes with PLT completely
> correctly, and with it my SSAX port works completely:

In looking for a solution that meshes well, I've experimented with
adding a `prop:exn:escape' property that the default uncaught-exception
handler recognizes and uses instead of calling the current error escape
handler. I haven't committed that experiment to SVN, though; it doesn't
seem useful when mixed with `with-handlers' (or `guard'), so I'm not
sure the tiny increment in R6RS interoperability is useful enough to
keep.


Matthew



Posted on the users mailing list.