Am Fr., 23. Juli 2021 um 19:20 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>:

On Fri, Jul 23, 2021 at 9:24 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

So implementations that add R6RS support could keep their existing
native exception hierarchy, and make those exceptions use
R6RS-compatible compound condition objects with R6RS-compatible simple
conditions as members. This should solve all interop problems?

As you say... under the condition (no pun intended!) that the native exception objects are compatible with compound conditions.

Fantastic! One of my biggest disappointments with R7RS Small was that we weren't able to provide an exception hierarchy compatible with R6RS — or even one at all. If there's a way for implementations that have their own hierarchies to, as much as possible, also support the R6RS hierarchy, that would be a boon to portable code.

In fact, an implementation doesn't even have to support R6RS-like compound objects natively. The only portable way to get hold of such an exception object is through the `with-exception-handler' procedure and the derived `guard' form. Thus it is enough when `with-exception-handler' replaces whatever native object with a compound condition (bundling the native object) before it is presented to the user-provided exception handler.

@Arthur: Do you remember why WG1 thought that it wouldn't be possible for the implementations that R7RS-small targets to provide an exception hierarchy compatible with R6RS?