> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Sunday, August 16, 2020 10:26 AM
>
> Thank you very much for your quick response.

You're very welcome; getting SRFI 170 finalized is a very very high
priority of mine right now, so this SRFI 198 which it currently is
gated on is of equal priority.

> Am So., 16. Aug. 2020 um 17:04 Uhr schrieb <xxxxxx@ancell-ent.com>:
>
>>> I have three questions concerning this [ old draft of the SRFI ]:
>>>
>>> (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
>
> [ Reply with info on R6RS, and SRFIs 18 and 35. ]
>
> > (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!

Indeed, Texas Instruments has an extremely cool line of 16 bit
microcontrollers that use FRAM instead of flash for persistent memory.
Much more durable than flash, enough to use without concern for the
likely life of the device, and it's bit addressable.  So while they're
made on an old enough process they aren't energy efficient while
running, it's very easy and quick to save any state in the small
amount of SRAM they have and then go into a very deep sleep.

The "biggest" model which I have a development board they supply
has a 256 KiB FRAM budget (alas, not contiguous) and 8 KiB SRAM.
Being PDP-11 and 8086/8 old school (it uses the later's style of
extended memory addressing, but alas no large data, small code
model in their supplied compiler), these are budgets I'm used to
working within.  Hope to get back to this soon, but a COVID-19
required backup program which uses SRFI 170 & soon 198 comes first.

(View me more a user of Scheme than a PL type like you.  Which of
course fits well with R7RS-large's ambitions.)

> 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: ...

Sure.

>>> (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?

No idea, I've always used non-continuable exceptions in my work by intent,
but continuable ones were there in R7RS-small, so I thought, why not?

- Harold