[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Exceptions on JVM [was: Exceptions needs examples]
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
per@x http://per.bothner.com/
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports