Re: Comments on draft #3 Marc Nieper-WiÃkirchen 04 May 2020 09:34 UTC
This is still a very partial reply. More comments will follow some time. Am So., 3. Mai 2020 um 00:56 Uhr schrieb John Cowan <firstname.lastname@example.org>: >> (2) In EITHER-REF, it should be an error if the default value of >> FAILURE is invoked and the Left payload consists of zero or more than >> one value. (This allows the implementation to do what is currently in >> the spec, but it shouldn't be mandated because it somehow muddies the >> idea multiple values. In a Scheme where the RAISE procedure is >> multiple-values-aware and can thus take more than one value or zero >> values, RAISE should be applied to the Left payload without a change, >> which the current spec wouldn't allow.) > > > Lefts now contain exactly one value. Where a Nothing has to be changed into a Left, there is an *obj* argument. 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. For that to work, Lefts must be able to contain an arbitrary number of values. In Scheme code such a Python-style generator could look like the following (with a better name, of course): (make-coroutine-either-generator (lambda (yield) (yield 1 2) (yield 3 4) (values 5 6))) This would return the following sequence: (right 1 2), (right 3 4), (left 5 6). Whether or not one wants to specify such types of generators, restricting Lefts to just one value is an unnatural restriction.