Thank you very much for your quick response.

Am So., 16. Aug. 2020 um 17:04 Uhr schrieb <xxxxxx@ancell-ent.com>:

> Note Draft #3 is *extremely* obsolete.  I have a more up to date
> version at https://htmlpreview.github.io/?https://raw.githubusercontent.com/hga/srfi-198/master/srfi-198.html

Ah, okay.

> but it reflects nothing after Lassi changed his mind about 'set being
> required and plists as the standard key/value pair collection type.

> > raise-foreign-error constructs a foreign-error-object like
> > make-foreign-status, and raises an exception in a manner suitable
> > for the Scheme implementation it is running on.
>
> Back to you:
>
> > I have three questions concerning this:
> >
> > (1) What does "in a manner suitable for the Scheme implementation it
> > is running on" mean?
>
> I'm trying to avoid specifying exactly what raising an error means.
>
> Besides not knowing anything about R6RS's exception system, it could
> be something different than a conventional R6RS/R7RS raise if that
> concept doesn't exist because it's a Scheme subset or R5RS or earlier

The R6RS exception system is not different from the R7RS (and SRFI 18)
exception system; it just adds a set of standardized error objects
(called conditions) and forces implementations to signal much more
errors than R7RS does.

(SRFI 35 also defines some standard error objects; that's why I have
been wondering whether it makes sense to build on prior art that is
already implemented.)

> (e.g. I'm working on a R4RS based one that should be able to run on
> 16 bit microcontrollers with more than 64KiB memory/address space).

That sounds very cool!

So... what about adding something along the lines of the following:

(A) In an R6RS or R7RS system or in a system support SRFI 18, raising
an exception means to call "raise" on the exception.
(B) In a system just supporting SRFI 23, raising an exception means
calling "error" with "message" and "irritants" as follows: ...

> > (2) What does "ideally raise a continuable exception" mean?
>
> Continuable exception in the sense of R7RS, but the entire concept has
> been dropped from the API, see above personal repo draft text.

What would have been the use cases for continuable exceptions? Did you
have any error objects arising in SRFI 170 in mind that could benefit
from a continuable exception?