From: Matthew Flatt <firstname.lastname@example.org> To: email@example.com Subject: [plt-scheme] 369.2 Date: Wed, 20 Dec 2006 09:08:31 0800 MzScheme and MrEd are now version 369.2 in the SVN repository trunk. This version includes another round of backward-incompatible changes, as described below. Matthew Exception Handling ------------------ The `current-exception-handler’ parameter no longer exists. Exception handlers installed with `with-handlers’ are instead associated directly with a continuation, with means that they work in a sensible way with delimited continuations. A new `call-with-exception-handler’ function takes over the role of using `parameterize’ with `current-exception-handler’ (but, again, associates the handler directly with the continuation, instead of going through a parameter). A new `uncaught-exception-handler’ parameter is called to handle exceptions when the current continuation has no handler. This parameter value is inherited in the usual way by new threads. The `initial-exception-handler’ parameter is gone. The default error escape handler aborts the current continuation using the default continuation prompt tag, supplying the `void’ procedure as the abort argument. In general, escape handlers that use `abort-current-continuation’ can work in any continuation (unlike abort handlers that jump to an escape continuation), so the error escape handler is also inherited as-is by new threads. Since the `uncaught-exception-handler’ and `error-escape-handler’ parameters are inherited by threads, all parameters are now inherited in the same way (i.e., there are no special rules for the exception-related parameters). Existing code that uses `with-handlers’ should work fine. Only programs that directly manipulate `current-exception-handler’ or `initial-exception-handler’ need to change. For those (relatively rare) programs, it’s usually straightforward to switch to either `uncaught-exception-handler’ or `call-with-exception-handler’. Interaction and Prompts ----------------------- The `read-eval-print-loop’ procedure, default load handler, and top-level `begin’ form now each install a prompt around each evaluation. This change greatly simplifies the implementation of the REPL --- that’ s what prompts are for, after all --- and it makes a lot more things work, such as > (define k #f) > (thread (lambda () (let/cc id (set! k id)))) #<thread> > (sleep 0.1) > (k 1 2 3) 1 2 3 Changing the load handler makes `load’ behave like the REPL: you can put the REPL expressions above in a file, and they work the same when you load the file. Also, you can load something like (define k (let/cc k k)) (thread (lambda () (k 2))) (sleep 0.1) and `k’ will get set to 2 with no "the port is closed" error. Finally, by having a top-level `begin’ install prompts around its subexpressions, wrapping any subset of the expressions with `begin’ does not change the result. There’s one interesting technical point related to the REPL and load-handler prompt. The abort handler for the REPL prompt takes a thunk and calls it, so that the results are sent to the printer. Thus, when an error aborts, then `void’ is called and the void value is sent to the printer (where it’s ignored). The load handler and `begin’, in contrast, install an abort handler that re-aborts, propagating the abort arguments. Thus, when an error aborts during a load or `begin’, then entire `load’ or `begin’ aborts. This is another example of the expressive power of prompt handlers in Sitaram’s design. Syntax Changes -------------- The `read-eval-print-loop’ procedure and default load handler wrap each top level `datum’ as `(#%top-interaction . datum)’ before evaluating. MzScheme exports `#%top-interaction’ as a macro that expands to just the `datum’. Other `module’-based languages can define `#%top-interaction’ to control the way that top-level interactive forms are processed, somewhat like `#%module-begin’ within a `module’ body. Only slightly related is the new `#%expression’ form, which forces interpretation of its body as an expression, rather than a definition or top-level form. For example, (begin 1 2) as a top-level expression wraps the evaluation of `1’ and `2’ with a prompt, but (#%expression (begin 1 2)) merely sequences the evaluation of the expressions `1’ and `2’. Ports ----- The new `prop:input-port’ and `prop:output-port’ properties can be attached to structure type so that its instances are treated as input ports or output ports, respectively. A structure instance can be both an input port and an output port (and an event, and a procedure, etc.). In the C API, SCHEME_INPORTP() and SCHEME_OUTPORTP() still recognize only the built-in port types, where casts to Scheme_Input_Port* and Scheme_Output_Port* are ok. The new SCHEME_INPUT_PORTP() and SCHEME_OUTPUT_PORTP() predicates recognize all ports, including structures with the corresponding property. Use the new scheme_input_port_record() and scheme_output_port_record() functions to get the corresponding Scheme_Input_Port* or Scheme_Output_Port*. Other ----- #\u0085 is now whitespace.