John, Wolfgang,

many thanks for your effort with this great SRFI. Please excuse that I
come up with another large number of comments, but most are minor.
Take my unabated insistence to help shape this SRFI toward perfection
as my way to express my esteem of your SRFI.

(1) "Because the procedures of Scheme, unlike the functions of ML and
Haskell, accept multiple arguments and return multiple values, this
SRFI allows a Just or Right container to hold more than one object.
The specification presented here, therefore, differs in several ways
from its analogues in other languages."

Here, "Left container" seems to be missing among "Just or Right
container". Apart from that, I wonder whether the terminology
"container holding more than one object" is a good one in this
instance because it can lead to the same kind of confusion, Shiro
mentioned this morning. I leave it to the native speakers to think of
a better English word. :)

You may want to replace "more than one object" with "more than one
object or no object".

(2) It may make sense to add a linear update procedure `either-swap!'.

(3) Are there any guarantees stated in the actual specification that
the "types" defined in this SRFI are disjoint to other Scheme types.
In SRFI 146, I have used the language "Mappings form a new type as if
created by define-record-type. The effect of using record-type
inspection or inheritance for the mapping type is unspecified.", which
hopefully addresses Will Clinger's concerns about what had been
established wording ([1]). Of course, we want these guarantees.

(4) Do we really want to restrict `equal' to an equivalence predicate
in procedures like `maybe=' or `either='? A predicate like ´<' would
also have its use cases. For that, the order of the arguments has to
be specified, of course.

(5) As discussed in another thread with Shiro, the default argument to
`failure' in `maybe-ref' can be made implementation-specific and
SHOULD default to a procedure that raises an error.

(6) For clarification, the introductory paragraph under "Sequence
Operations" may go into the rationale (as well).

(7) `pred' and `success' are currently defined to "accept one or more
arguments". This has to be corrected into "accept zero or more
arguments" to handle Justs, Lefts and Rights whose payload has the
shape of zero values correctly.

(8) What is the logical meaning of `proc' and `mproc' not accepting
arguments wrapped into containers? This cannot be meant literally. It
is probably better to just remove that clause.

(9) `either-filter' and `either-remove' should take multiple obj
arguments (including) for consistency and regularity. The same goes
for `maybe->either'

(10) `maybe-sequence' and `either-sequence' take a `traversable'
argument, but this kind of object seems to be not specified. Why do we
restrict `map' to just one argument, shan't we allow an arbitrary
number of arguments and get rid of `aggregator' this way?

(11) The example to `either-sequence' uses the `identity' procedure.
This procedure is called `values' in Scheme (one SRFI, namely SRFI 41,
mentions a procedure named `identity', but it doesn't seem to be part
of SRFI 41's interface).

(12) `maybe->either' and `either->maybe' speak of "the same payload in
the sense of eqv?". This doesn't make sense because payloads are no
first-class objects that can be compared using eqv?. I suggest adding
something like the following at the top of the specification: "When
this SRFI speaks of two payloads being equal in the sense of eqv?, it
means the payload consists of an equal number of objects and each pair
of corresponding objects is equal in the sense of eqv?." This would
apply to the wording of, say, `either-swap' as well.

(13) Please, please, reconsider the specification of `maybe->list' and
`either->list'. It would be much more regular and helpful if these
procedures returned #f in case of a Nothing (instead of the empty
list) and, by regularity, in case of a Left as well. In Scheme, nil is
a different value than false. Let's make use of this advantage!

(14) The problem with the maybe->values/value->maybe and
either->values/values->either procedures is that they do not really
set up a bijection. A Just or a Right with no values would be
indistinguishable from a Nothing or a Left, which is just bad. A
simple way-out would be to say that it is an error if the Justs or
Lefts do not contain a single value as their payload. Likewise, the
procedures values->maybe/values->either should only accept zero or one
value.

(15) For consistency and regularity, `values->either' should accept an
arbitrary number of objs (including zero). The same is true for
`lisp-values->either'.

(16) The `producer' protocol used in `values->maybe' and
`values->either' (the same as in `call-with-values') make the job of
an optimizing compiler unnecessarily hard ([2]). If `values->maybe'
and `values->either' were syntax, it would be a lot easier.
Unfortunately the forthcoming multiple values SRFI is not yet ready;
otherwise, we might reuse some of its idioms.

(17) `lisp-values->maybe' and `lisp-values->either' have the same
problem as maybe->values/either->values in that zero values are
conflated/confused with Just/Right payloads consisting of zero values,
which can lead to confusion and code that is hard to reason about. The
simple way out is to make it an error if `producer' returns more than
one value. (This way, an implementation can still decide to extend the
domain so that it works like in the current draft, although I wouldn't
recommend it for the above reasons.)

(18) That the `successor' argument in `maybe-unfold' and
`either-unfold' is not being used smells a bit [can one say so in an
analog of "code smell"?]. The two procedures would be regular with
respect to the various unfold procedures in R7RS-large if, after the
seeds are stored as a payload, the successor is called on the seeds
and if the stop procedure then doesn't yield #f on the resulting
values. This can be important if the successor procedure has side
effects or raises an exception or deals in another way with
continuations. This way, `maybe-unfold' and `either-unfold' become
true drop-ins for, say `unfold' of SRFI 1.

(19) I still think that it is an error that the error MUST be
signaled. I still propose to change the wording so that an error
SHOULD be signaled ("encouraged" in the RNRS terminology) as this
would not preclude Schemes offering a fast unsafe execution mode.

(20) What about a `maybe-case' as well? In `maybe-if', the payload of
the Just is thrown away, which is not what we always want.

(define-syntax maybe-case
  (syntax-rules (just nothing)
    ((maybe-case e ((just . arg*) . body1) ((nothing) . body2))
     (maybe-ref e (lambda () . body2) (lambda arg* body1)))))

A similar definition can be made for `either-case'.

Thank you for still reading up to this point!

Marc

--

[1] https://srfi-email.schemers.org/srfi-137/msg/3937357/
[2] https://dl.acm.org/doi/10.1145/182590.156784

Am Mi., 3. Juni 2020 um 00:25 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Tue, Jun 2, 2020 at 12:12 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
>
>>
>> These are some very old changes.
>
>
> I'm terribly sorry.  That was the result of a cascade of errors.  I somehow managed to omit the line for draft #4 in the Status section when publishing that draft last month, so when I went to publish this one, which is actually draft #5, I was off by one.
>
> Let me try again:
>
> ________________________________
>
> I've just published draft #5 of SRFI 189. It was submitted by John Cowan, co-author of the SRFI.
>
> Here are John's comments on the draft:
>
> I think this is ready for last call now. Wolfgang's implementation will catch up shortly.
>
> Note that I am waiting to announce last call until the implementation and tests are complete.
>
> Here is the commit summary:
>
> Implement Draft #4 changes.
> Update either-filter and either-remove to draft #4.
> Update tests.
> Provide the list of payload values when calling error.
> Left takes multiple values; added examples
> typos
> severed values->maybe/either from lisp-values->maybe/either
> minor inconsistencies
> oops
> Add missing "#f".
> Publish fourth draft.
> Publish fifth draft.
>
> Here's the diff:
>
> https://github.com/scheme-requests-for-implementation/srfi-189/compare/draft-4..draft-5
>
> Regards,
>
>
> SRFI Editor