[plt-scheme] SXML for R6RS [was: R6RS Interoperability]
At Thu, 10 Jul 2008 00:36:32 -0700, Derick Eddington wrote:
> On Wed, 2008-07-09 at 07:18 -0600, Matthew Flatt wrote:
> > Suppose that you actually want ports to be closed when control escapes
> > (for any reason), so you write
> >
> > (define (call-with-input-file* file proc)
> > (let ([p #f])
> > (dynamic-wind
> > (lambda () (set! p (open-input-file file)))
> > (lambda () (proc p))
> > (lambda () (close-input-port p) (set! p #f)))))
> >
> > and use that, instead. Then, doesn't my objection about `ssax:warn' and
> > `guard' hold?
>
> Using dynamic-wind like that would have the same issue with any possible
> exception re-raised by a guard, and if there were multiple guards which
> re-raise, it would exit and re-enter for each guard. Or what if
> somewhere down in proc's dynamic extent it uses a procedure which
> escapes to some continuation and then re-enters back? Assuming the
> dynamic extent will only be entered and exited once just seems like a
> bad idea unless you can be certain of that.
You're right.
Under normal circumstances, you can be sure quite often, because few
library functions capture and restore continuations. Indeed, in
building PLT Scheme libraries and tools, we've often found it necessary
to ensure that a continuation is not restored when unknown code is
called, which is why PLT Scheme includes constructs like continuation
barriers.
> I don't see how making ssax:warn raise an exception
> singles it out when there are other ways control could escape and
> re-enter.
Turning the above around, if a library captures and restores
continuations, then it's placing an extra burden on users of the
library to accommodate continuation jumps. That sounds like a big price
to pay to get warnings from SSAX --- but perhaps I'm not enough of an
SSAX user to say. If SSAX users understand that functions capture and
restore continuations anytime that they might report a warning, and if
they're happy with that API, then it's all fine.
Matthew