SRFI 113 minor issue with tests in implementation Sudarshan S Chawathe (25 May 2018 00:18 UTC)
Re: SRFI 113 minor issue with tests in implementation John Cowan (27 Aug 2018 19:14 UTC)
Re: SRFI 113 minor issue with tests in implementation Arthur A. Gleckler (27 Aug 2018 20:59 UTC)
Re: SRFI 113 minor issue with tests in implementation Marc Nieper-Wißkirchen (28 Aug 2018 08:09 UTC)
Re: SRFI 113 minor issue with tests in implementation Marc Nieper-Wißkirchen (28 Aug 2018 13:38 UTC)
Re: SRFI 113 minor issue with tests in implementation John Cowan (28 Aug 2018 14:17 UTC)
Re: SRFI 113 minor issue with tests in implementation Arthur A. Gleckler (28 Aug 2018 15:12 UTC)
Re: SRFI 113 minor issue with tests in implementation Marc Nieper-Wißkirchen (28 Aug 2018 15:49 UTC)

SRFI 113 minor issue with tests in implementation Sudarshan S Chawathe 25 May 2018 00:18 UTC
Minor issue related to tests in the sample implementation of SRFI 113
(and as also included in SRFI 146's implementation).  I'm posting this
note mainly because it may save someone else some time.

The test groups "sets/mismatch" and "bag/mismatch" include several SRFI
64 test-error cases. However, when used for "is an error"
(a.k.a. "anything goes") situations, many of these test-errors (can)
cause test failures in the sample implementation.

My reading of that SRFI 64's test-error is that it should be used only
in situations where the implementation is obligated to detect an error,
not in "is an error" situations.

I encountered this issue while working with the SRFI 146 sample
implementation and Kawa.  I had tested earlier with Chibi which skips
the test-error cases (at least on my setup) so the issue did not arise
then.  (So I should add a caveat that my testing is with the code
included in the SRFI 146 sample implementation, not the original SRFI
113 code.  I also tweaked the implementation a bit to account for Kawa's
restricted call/cc, but I don't think that should matter.)

In any case, I am attaching a diff with the changes I made to SRFI 113's
test.sld file.  (I'm hoping it's small enough to be OK.) Mainly, I put a
few test-expect-fail calls before the problematic test-error cases.  It
also includes some trivial renaming to avoid the duplicate defines I
noted in an earlier message (to the SRFI 146 list).

Regards,

-chaw