[plt-scheme] 299.6
The v299-tagged code in CVS for MzScheme and MrEd is now version 299.6.
(The exp-tagged code remains version 206.1.)
Changes:
* Added `current-parameterization' and `call-with-parameterization'.
Long-time MzSchemers may recall that parameterizations were
first-class values back before version 100. We removed them in
version 100, because they created to sharing problems with threads.
The new parameter system (based on continuation marks and thread
cells, essentially as in Scsh) eliminates the sharing problem, while
making parameterization values more useful than ever. For example,
first-class parameterizations enable better break support in
`with-handlers'.
* Breaks are disabled (by default) for `with-handlers' predicates and
handlers.
Making the predicate non-breakable is almost certainly a good idea.
Probably lots of existing code could fail due to an expected break
during calls to predicates.
It's not clear that a non-breaking handler is a good idea, though.
For example,
(let loop ()
(with-handlers* ([(lambda (x) #t) (lambda (exn) (loop))])
(/ 0)))
used to be a breakable infinite loop, but now it's an infinite loop
that becomes non-breakable right away.
I think that many handlers perform a clean-up action or record the
exception, though, so they shouldn't be interrupted.
FWIW, here's a variant of `with-handlers' that disables breaks for
predicates, but restores the original break parameterization for the
handler:
(define-syntax with-handlers*
(syntax-rules ()
[(_ ([pred handler] ...) expr0 expr ...)
(let ([p (current-parameterization)])
(with-handlers ([pred (let ([orig handler])
(lambda (exn)
(call-with-parameterization
p
(lambda () (orig exn)))))]
...)
expr0 expr ...))]))
* An exception handler or `dynamic-wind' pre/post thunk is called in a
parameterization that disables breaks, and the handler/thunk can
re-enable breaks (during the thunk's execution) through the
`break-enabled' parameter.
Previously, breaks were disabled in exception handlers and pre/post
thunks through an internal flag (for performance reasons), and the
flag could not be overridden.
Mutating the `break-enabled' parameter inside an exception handler
or pre/post thunk has no effect outisde the handler/thunk, unless it
explicitly manipulates the current parameterization. This change
might break some existing code, but such code is better written in a
different way (probably with `call-with-parameterization') in v299.
* Cleaned up the handling of exceptions during the exception handler:
- While an exception handler is called, the current exception
handler is reset to the default handler (through a
`parameterize').
More precisely, it's set to a handler that constructs an
'exception raised by exception handler" exception, and passes
that on to the default exception handler. The text of the
generated exception includes the text of the original exception,
as well as the text of the exception raised by the exception
handler.
- Similarly, the error display and escape handlers are called by
the default exception handler in a `parameterize' tat restores
the corresponding default handlers.
An exception handler can handle exceptions that are raised during
the handler (by using `with-handlers' or setting the
`current-exception-handler' parameter). Previously, special handling
of exceptions-during-exceptions was enabled through an internal
flag, which couldn't be overridden.
* During the evaluation of dynamic-wind pre and post thunks, the
current continuation marks and parameterization are reset to those
active at the time of the dynamic-wind call (except that the
parameterization is extended to disable breaks).
This change corrects a bug that made the new `parameterize' interact
with `dynamic-wind' differently than in v206 (in the single-threaded
case). It probably also fixes undiscovered bugs in constructs that
are built on continuation marks.
* Added a `current-compile' parameter, which is used by `compile' and
by the default evaluation handler.
Errortrace now sets this parameter, instead of `current-eval'.
Matthew