Am Sa., 4. Juli 2020 um 02:48 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> Not an oversight, because Wolfgang and I had not yet thought of it.  Added and pushed, along with much more detail for maybe/either-let*.

+1 for XXX-let*-values

>>  PS The SRFI uses the language "an error is signaled" in conjunction
>>
>> with the new syntax again. That's an error, which I am herewith
>> signaling again. Unfortunately, the signaled error hasn't been caught
>> by the SRFI's author yet. :)
>>
>>
>> (The impossibility to write a robust test for this requirement proves
>> one shortcoming.)
>
>
> It's true that a test for something that signals an error is not robust in the presence of asynchronous exceptions, as we discussed earlier.  But in fact *no* test, not even (test (= (+ 2 2) 4))), is robust in the presence of an asynchronous exception. A simple wrapper like:
>
> (define-syntax error-signaled?
>   (syntax-rules ()
>     ((_ expr)
>      (with-exception-handler
>        (lambda (e) #t)
>        (lambda () expr #f)))))
>
> (or something to that effect) should suffice.

The basic problem is not asynchronous exceptions, the problem is that
your test cannot test the kind of error that has been raised. It can
be the error signaled due to providing a value, which is not a Just or
a Maybe, or it can be an error because some other code path in the
implementation has gone wrong.

I know that I am repeating myself but that doesn't make it less true:
Signaling an error without a corresponding predicate is rather
pointless.

That said, in the R7RS language so far, errors are not signaled (in
the sense of the R7RS) for programming errors (e.g. applying 'car' to
a number or providing a non-Maybe to 'maybe-if') but implementations
are encouraged to report such errors to the user (instead of making
demons fly out of your nose) and every sensible implementation (unless
in unsafe mode) follows this advice.

Errors that are signaled in the technical sense are *not* programmer
errors but unforeseeable environmental errors. In the R7RS-small,
there are mostly file errors and reader errors.

This is in stark contrast to the current draft of SRFI 189, which uses
the phrase for programming errors (e.g. type errors).

So please correct the language before SRFI 189 is finalized. The
sample implementation can, of course, continue to raise an error to
follow the encouragement to report an error to the user. (Or, better,
use 'assume' from SRFI 145, which is exactly there for these
purposes.)

Marc