From: Matthew Flatt <>
Subject: [plt-scheme] 299.6
Date: Tue, 27 Apr 2004 14:30:57 -0600

The v299-tagged code in CVS for MzScheme and MrEd is now version 299.6.
(The exp-tagged code remains version 206.1.)


 * 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

 * Breaks are disabled (by default) for `with-handlers’ predicates and

   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

       (define-syntax with-handlers*
         (syntax-rules ()
           [(_ ([pred handler] ...) expr0 expr ...)
            (let ([p (current-parameterization)])
              (with-handlers ([pred (let ([orig handler])
                                      (lambda (exn)
                                         (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

       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

     - 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’.