Am Mo., 8. Juni 2020 um 16:29 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

If we were defining exceptions de novo, this would be a very useful distinction, more or less comparable to the Java distinction between Exception and Error. However, making it now is not only backwards incompatible with R7RS-small, but is a big non-portable change in an area where implementers have historically pushed back on any attempt at systematization.

Two objections:

(1) We are only talking about situations "where it is an error" and not "where an error is signaled". Even when an implementation somehow signals to the user that there is "an error situation", R7RS-small does not force the implementation to use standard exception system nor does it forces the implementation to make these error catchable. In fact, it often doesn't make sense to catch these errors because they are completely opaque to portable code.

All that has been proposed (if I have understood correctly) is to actively suggest to implementations making this distinction so that an unqualified `guard' or `with-exception-handler' does not catch low-level, non-portable exceptions.  These should be caught by implementation-specific code.

(2) History may change.

Therefore, I am going to go with (exception->either pred thunk), which invokes thunk and returns its values wrapped in a Right, unless an exception satisfying pred occurs, in which case the exception is wrapped in a Left and returned.

My proposed name `either' wasn't a good one, but `exception->either' is neither a good one and possibly worse.  Quoting the R7RS: "By convention, "->" appears within the names of procedures that take an object of one type and return an analogous object of another type."  Thus `exception->either' is a very misleading name. (By the same measures, I neither like `values->either' and hope for a better name before the final version, although it is slightly better.)

`exception->either' works like some kind of guard. Maybe this can be reflected by its name.  If all exceptions were caught, `make-either' wouldn't have been such a bad name because exceptions should be the exceptional case, so `make-either' would mostly just make an Either from the values produced with the extra condition that exceptions are caught and wrapped as well.