[plt-scheme] 369.2

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.