Email list hosting service & mailing list manager

Bug in SRFI 1 implementation Chris Hanson (27 May 2020 02:56 UTC)
Re: Bug in SRFI 1 implementation Chris Hanson (27 May 2020 03:04 UTC)
Re: Bug in SRFI 1 implementation Alex Shinn (27 May 2020 04:23 UTC)
Re: Bug in SRFI 1 implementation Shiro Kawai (27 May 2020 09:53 UTC)
Re: Bug in SRFI 1 implementation Arthur A. Gleckler (28 May 2020 00:09 UTC)
Re: Bug in SRFI 1 implementation Alex Shinn (28 May 2020 00:18 UTC)
Re: Bug in SRFI 1 implementation Arthur A. Gleckler (28 May 2020 01:59 UTC)
Re: Bug in SRFI 1 implementation Alex Shinn (28 May 2020 02:53 UTC)
Re: Bug in SRFI 1 implementation John Cowan (28 May 2020 14:37 UTC)
Re: Bug in SRFI 1 implementation Marc Nieper-Wißkirchen (28 May 2020 14:55 UTC)
Re: Bug in SRFI 1 implementation John Cowan (28 May 2020 17:40 UTC)
Re: Bug in SRFI 1 implementation Marc Nieper-Wißkirchen (02 Jun 2020 09:50 UTC)
Re: Bug in SRFI 1 implementation Arthur A. Gleckler (02 Jun 2020 17:22 UTC)
Re: Bug in SRFI 1 implementation Arthur A. Gleckler (02 Jun 2020 22:53 UTC)

Re: Bug in SRFI 1 implementation Marc Nieper-Wißkirchen 28 May 2020 14:55 UTC

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)))))))
>>
>>