I would always be in favor of removing all such libraries on the DRY principle. To do otherwise suggests that the newer SRFI depends on some specific (possibly outdated) version of the older SRFI's code. People who have access to a SRFI should be assumed to have access to all SRFIs, at least those with portable implementations.

I made an exception for SRFI 158 because it deprecated the original SRFI 121 rather than just depending on it, but maybe that's a bad idea too; there is the same problem of fixing bugs twice. I'll look into it when I get a minute.

On Fri, Mar 20, 2020 at 11:36 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

Am Fr., 20. März 2020 um 00:01 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>:
On Thu, Mar 19, 2020 at 3:06 PM Sudarshan S Chawathe <xxxxxx@eip10.org> wrote:

Going over the SRFI 128 mailing list archives, I found that the bug was
fixed by Will Clinger in May 2016, but that fixed version does not seem
to have made it over to the SRFI 146 code.

Aha, I should have updated SRFI 146's copy, too.

I think one fix is pretty simple; just syncing up the SRFI 128 files
should do it. However, perhaps a better fix is to unbundle the SRFI 128
implementation from the SRFI 146 code in order to avoid similar issues
down the road.

I agree. Marc, may I remove the copy of SRFI 128's sample implementation from SRFI 146's repository, replacing it with a README file pointing people at the canonical repo?

The repository does not only contain an implementation of SRFI 128 but also of some other SRFIs like SRFI 8 to make it as self-contained as possible. We should either remove all or none of these supporting libraries.

What about resyncing the copy of SRFI 128 in SRFI 146's repository and adding a note in the README that the contributed supporting libraries may be out of sync?

Marc

Thanks for the report, Sudarshan.