On Sun, Jun 20, 2021 at 2:55 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

Meaning code intended to be portable among SRFI 113 implementations has to ignore the PFN, so we would still be missing a fully imperative/mutative version of sets and bags.

That's not how PFNs work. A PFN, like an ISO TC, is a lightweight way of creating a new spec. So you don't claim conformance to SRFI 113: you claim conformance to SRFI 113 with no PFNs, or with PFN 1, or with PFNs 1 and 2, or .... Otherwise, for example, implementing SRFI 113 would require support for SRFI 114 comparators, which have been withdrawn.

(There are some PFNs that are clarifications only, like those attached to SRFI 179.)

(It would really be a smaller change to swap the sample implementation of SRFI 113 and to leave the API functional as a counterpart to SRFI 146.)

How is that not redundant with 146, then?