Am Di., 7. Juli 2020 um 22:32 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> (1) What happened to exception-guard? The only thing that seemingly

Sorry; I meant 'either-guard', of course.

>> spoke against it was the implementability.
>
>
> There is also the issue of trapping asynchronous or otherwise unpredictable exceptions that should not be trapped.  But I left it out because I was in doubt, as the rhyme has it.  It's easier to add things when they are wanted than to remove them.

We have also solved the issue of trapping unpredictable exceptions by
adding a mandatory 'pred?' argument to 'either-guard'.

While it is true that this syntax can always be added later (as can,
in principle, every part of this SRFI), it would be unfortunate to
leave out exactly 'either-guard' because it will certainly be used
much more often than a number of other procedures in this SRFI and
sets a clear style for idiomatic code:

(either-guard read-error? (read))

>> (2) As a number of additions/changes have already been made since this
>> last-call period,
>
>
> In fact there are none since #8, other than editorial corrections and the addition of maybe-let*-values and its either- equivalent (which you were in agreement with).  If you have  specific additional proposals or have found errors, by all means tell us about them, but if we don't hear by the 9th or so (7 days after the second last call), we'll finalize.

I thought there had been more changes and I was wondering whether more
than those few people who have posted recently were paying attention.
Obviously, I was wrong with the number of additions/corrections.

PS: The "an error is signaled" error is still in the current draft.