On 01/08/2014 08:28 PM, Michael Montague wrote: > R7RS states that "the (exception) handler is called with the same > dynamic environment as that of the call to 'raise'... How is Kawa making > this happen? Looking in exceptions.scm: 'with-exception-handler' > contains a try-catch so it looks like the exception handlers will be > called in the same dynamic environment as 'with-exception-handler'.
Indeed, for 'raise' Kawa unwinds the stack before evaluating the handler, which isn't 100% right. I agree it should be possible to construct programs where this matters. My hunch is that it would be rare to find a "natural" program where it matters, especially one where Kawa's other restrictions (such as no full call/cc) aren't an issue. It's a trade-off. I think it's desirable that with-exception-handler and guard can handle "native" JVM exception. Also, for performance reasons, we prefer to inline at least the "body" thunk, and ideally also the handler code. It is very important to inline the "body" thunk: It's not an issue of the procedure call overhead, but that using a procedure really hurts register allocation and other JVM optimizations, plus its requires allocating a closure To test the implementation, I've been contributing tests to Alex Shinn's r7rs-tests.scm (in the Chibi repository); this is the Kawa version: https://sourceware.org/viewvc/kawa/trunk/testsuite/r7rs-tests.scm Kawa passes all the existing tests (except that file-error? is not true as it should be for the exception thrown by delete-file). Which suggests the implementation is "good enough". To change Kawa's implementation I need example code that fails, preferably in a form suitable for the test-suite. (Unless it's to improve the performance, but that is not the issue here, I think.) But not only that: A test that is part of a test-case but uses convoluted unnatural idioms (while useful for a testsuite) is obviously relatively lower priority, especially if it is difficult to implement correctly or excessively hurts performance. > Here is a possible solution: > > If exceptions thrown by Java code get turned into Scheme exceptions > before the dynamic environment gets unwound, then it should be possible > to get very close to the full semantics for 'guard' and > 'with-exception-handler' without too much overhead. This can be done by > putting try-catch around the <body> of 'parameterize' and 'guard', and > the <thunk> of 'dynamic-wind'. > > (define-syntax parameterize > (syntax-rules () > ((parameterize ((param value) ...) . body) > <set params to values> (try-catch body (ex (raise ex)))))) I don't understand how this try-catch does anything. > The dynamic environment will need to be entirely in Scheme land; > 'dynamic-wind' can not use try-finally. In Foment, I use a separate > stack to maintain the dynamic environment and the same idea should work > for Kawa. As I said: It's a trade-off: Specification conformance, performance, native exception integration, and implementation effort are all factors. I'd like Kawa to have an option that supports full call/cc, full dynamic-wind, and exceptions 100% compliant with the spec. Someday ... (but even then that won't be the default). -- --Per Bothner [email protected] http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
