Am Di., 5. Mai 2020 um 03:05 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Mon, May 4, 2020 at 5:34 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> This will prevent the abstractions provided by SRFI 189 to be used in
>> some very natural contexts. One example is the Python generator
>> protocol, which yields values (one value in the Python case) on each
>> iteration and raises an exception (StopIteration in the Python case),
>> whose payload is the final return values (NB: not a concept of SRFI
>> 121/SRFI 158). If we want to model such a generator protocol using
>> SRFI 189, which is a very natural thing to do, the generator would
>> produce Rights as long as it is not exhausted. After the last
>> iteration, it will produce a Left whose payload is the return values.
>
>
> Rather, I think, it should return a Left of a condition object, which can be any value, simple or compound (see <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/CompoundObjectsCowan.md>, to which I have just added a multiple-value accessor).  Otherwise, the multiple-valuedness spreads from `raise` to `guard` to the explicit exception handlers of `with-exception-handler`.  Where does it stop?  I'm willing to have multiple-valued monads, but not multiple exception values.

While the extension of RAISE and WITH-EXCEPTION-HANDLER to multiple
values is straight forward, GUARD, which binds a variable, would have
to become GUARD-VALUES (as much as LET becomes LET-VALUES).

That said, I am not suggesting to make it part of any standard that
Scheme should support threading multiple values through the exception
systems, so don't worry :). But it is conceivable that some Schemes
want to do this (because it is not completely unnatural, especially
when exceptions are implemented with continuations). Therefore, we
should leave these corners unspecified.

Coming back to a generator protocol as Python has it: While Python
makes use of its exception system to signal the end of a generator,
this is an implementation detail. If Python-style generators are
redone in the Scheme world, it either makes sense to deliver the
values (and the final return value(s)) using Eithers or by using two
continuations, "success" and "failure", where "failure" should not
connote an error condition. In either case, the Scheme exception
system is unaffected.

What I am saying is: Right values signal regular values, Left values
signal singular values (I am using "singular" instead of "exceptional"
here so that it is not conflated with the technical meaning of
"exception" in Scheme). In some, but not all situations, the singular
values will be mapped to Scheme exceptions. In these cases, but only
in these cases, it should be an error if the payload of a Left
consists of less or more than one value. (And even then,
implementations are free to allow multiple values if their exception
system is suitably extended.)

The Either type of Haskell does also not have this restriction: The
type constructor is "Either a b" and "b" can be an arbitrary type
(recall that Haskell's static types correspond to arity and coarity in
Scheme).

Marc