Jim Rees <xxxxxx@gmail.com> schrieb am Do., 12. Apr. 2018 um 14:50 Uhr:

Thanks for your comments.

The tests rely on the default comparator comparing symbols in the suggested way in (srfi 128). But this is not required, and my own (srfi 128) does something else for performance.

This is true, indeed. While I think that it should be fixed at some point, it is not crucial: This SRFI ships with an implementation of SRFI 128, which works for the tests, and the implementation of SRFI 146 itself works with any SRFI 128 implementation.

Adding the following code before calling (make-default-comparator) and all the tests pass for me.

;; register a comparator on symbols:
(comparator-register-default!
(make-comparator
symbol?
eq?
(lambda (a b) (string<? (symbol->string a) (symbol->string b)))
symbol-hash))

This may not be the nicest fix as it mutates global state.

Registering a comparator for the type symbol? is an error by SRFI 128 so fixing this would require a bigger effort.

The most reasonable fix would be to use strings instead of symbols when the order matters.

The (srfi 146 hash test) had a similar failure with hashmap-pop, but the above fix didn't help -- probably depending on implementation-dependent symbol-hash -- so it was easier to change the test to assert that the popped key/value was one of 3 possible combinations.

(test-assert "hashmap-pop: non-empty hashmap"
(let ((result
(receive (hashmap key value)
(hashmap-pop hashmap1)
(list (hashmap-size hashmap) key value))))
(member result '((2 a 1) (2 b 2) (2 c 3)))))

Thanks! This test case is much better. Fixed.

Your (srfi 113) code has a discrepancy w.r.t. set-map/bag-map. The comparator argument is supposed to come first before the mapping procedure, at least according to the current checked-in spec, sample code, and tests.

Please see the post-finalization note 2 of SRFI 113.

-jim

On Wed, Apr 11, 2018 at 4:41 PM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
Marc Nieper-Wißkirchen, author of SRFI 146, Mappings, has asked me to announce "last call" for this SRFI. He believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.

<https://srfi.schemers.org/srfi-146>

In particular, I appeal to anyone reading this to try the sample implementation, run the tests, and send feedback about your results.

If you're interested in this SRFI, please give your feedback via the SRFI 146 mailing list before 2018/4/19. After that, assuming that no major revisions are required, we will declare it final.

Regards,

SRFI Editor