Allow customizing which exception types are show-stopping

[dpk]

What do you think of this as a solution to the issue raised in #1008 about some condition types, when raised continuably, returning control to the program?

This isn’t wired into the (chibi repl) exception handler yet as I wanted to get your feedback on this approach first.

[ashinn]

What do you think of this as a solution to the issue raised in #1008 about some condition types, when raised continuably, returning control to the program?

As I understand from the previous discussion, there is no issue. The R6RS standard doesn't specify anything about the REPL, so chibi is free to do what it wants.

[dpk]

The issue affects the top level exception handler in general. E.g. R6RS code which issues a warning by raising a &warning continuably should not cause the whole program to stop, even setting aside the REPL.

(The solution here is more general and allows any predicate applied to a raise-continuable’d object to be used to check whether that object should return control flow to the program.)

[ashinn]

The issue affects the top level exception handler in general. E.g. R6RS code which issues a warning by raising a &warning continuably should not cause the whole program to stop, even setting aside the REPL.

These patches are a good example of my complaints against R6RS 😞

R6RS adds too many new features to the core. Exception handling has to have a prescribed condition type with compound conditions, and the top-level has to have a special exception handler for a certain type of conditions. Moreover, these are (or were at the time of writing) experimental features, unlike any existing exception systems. Is anyone really using these continuable exceptions in real-world code?

I digress. And none of that is to say R6RS is bad, but rather that it doesn't attempt to build things on top of a small core. Chibi's raison d'etre is to be small (originally comparable in size to TinyScheme), and while nobody complains about the lack of R6RS support, I do get complaints about the gradual increase in size. Note Chibi does not even aspire to full R7RS large support.

So if the answer to every R6RS feature is "let's just add it init-7.scm" then we have a problem, and need to go back to considering a flag to instead switch to "init-6.scm".

For this particular change, I might consider a command-line flag to register an exception handler from a module (the code would be similar to the -t trace handling and should be ifdef guarded).

[dpk]

Moreover, these are (or were at the time of writing) experimental features, unlike any existing exception systems.

This is somewhat off-topic, but while I agree that some parts of the R6RS had this problem (IO, records, and enumerations in particular), this is not really true of the condition system. SRFI 34 (which gave us raise, with-exception-handler, and guard) and SRFI 35 form a pair, and predate the beginning of R6RS by several years. (rnrs conditions) is a minor (compatible) refinement of SRFI 35. These are among the more widely supported SRFIs. (Scheme 48 isn’t in that table, but it also supports this condition system, as you’d expect, given the SRFI authors.)

[ashinn]

Moreover, these are (or were at the time of writing) experimental features, unlike any existing exception systems.

This is somewhat off-topic, but while I agree that some parts of the R6RS had this problem (IO, records, and enumerations in particular), this is not really true of the condition system. SRFI 34 (which gave us raise, with-exception-handler, and guard) and SRFI 35 form a pair, and predate the beginning of R6RS by several years. (rnrs conditions) is a minor (compatible) refinement of SRFI 35. These are among the more widely supported SRFIs. (Scheme 48 isn’t in that table, but it also supports this condition system, as you’d expect, given the SRFI authors.)

raise-continuable is not in SRFI 34.

[ashinn]

Back on topic, I realize there's a much simpler solution here. Just put the overload of current-exception-handler in (rnrs base). You don't need to make it customizable, since R6RS doesn't allow this and nothing else will use it.

This will conflict with other attempts to install a top-level exception handler, but not the built-in one which gives advice on errors (except that it will be unable to give advice on warnings).