The future is longer than the past (at least we hope so), but it's the past that controls the present, and the present is a lot of unadapted or minimally adapted copies of SRFI 1.  Of course, one hopes that the predicate is usually an equivalence relation, in which case the bug does not matter.  But when it isn't, the user will read the SRFI, try to use the procedure, fail, and complain.  Changing the SRFI with a warning heads off a lot of complaints.

On Thu, May 28, 2020 at 10:55 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
The sample implementation of SRFI 1 contains a number of hints on how
to create implementation-specific optimized versions. As SRFI 1 is a
very basic library and probably be used by a lot of code, we should
really encourage implementers of Scheme systems to bundle their own
version of SRFI 1 and not just to copy the reference implementation.

Thus, the existence of the sample implementation is, in my opinion,
not a good reason to change the specification. There may be other
reasons why the specification should be changed and not the reference
implementation, but that would be due to factual reasons.

Am Do., 28. Mai 2020 um 16:37 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> I'm a little worried about changing the implementation and leaving it at that.  The SRFI-1 implementation is so widely disseminated that some systems will implement the patch and others will not, sacrificing existing interoperability for supposed specification stability.  (Chibi is the only implementation I know to have its own SRFI 1 implementation; are there any others?)
>
> ISTR that we did this once before, but I can't recall the details.
>
> On Wed, May 27, 2020 at 8:09 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>>
>> On Tue, May 26, 2020 at 7:56 PM Chris Hanson <xxxxxx@chris-hanson.org> wrote:
>>
>>>
>>> This flips the arguments but not the predicate. This can be fixed by flipping the predicate, or removing the statement from the document.
>>>
>>> Given that I’ve been using this implementation for many years, and this is the first time I noticed the problem, it might be simpler to remove the statement.
>>
>>
>> Since SRFI 1 was finalized long ago, it's too late to change the statement.  Fixing the sample implementation is fine, though.
>>
>> On Tue, May 26, 2020 at 9:23 PM Alex Shinn <xxxxxx@gmail.com> wrote:
>>
>>>
>>> Since the order is also specified for lset= I don't think we should change this, and simply consider it a bug in the reference implementation, which can be fixed with:
>>>
>>>   (and (%lset2<= = s1 s2)
>>>           (every (lambda (y) (find-tail (lambda (x) (= x y)) s1)) s2))
>>
>>
>> Does everyone agree that the above is a correct fix, i.e. that the definition below should be the new definition?:
>>
>>
>> (define (lset= = . lists)
>>   (check-arg procedure? = lset=)
>>   (or (not (pair? lists)) ; 0-ary case
>>       (let lp ((s1 (car lists)) (rest (cdr lists)))
>>         (or (not (pair? rest))
>>             (let ((s2   (car rest))
>>                   (rest (cdr rest)))
>>               (and (or (eq? s1 s2)            ; Fast path
>>                        (and (%lset2<= = s1 s2) ; Real test
>>                             (every (lambda (y)
>>                                      (find-tail (lambda (x) (= x y)) s1))
>>                                    s2)))
>>                    (lp s2 rest)))))))
>>
>>