Re: set-map and bag-map argument order
Arthur A. Gleckler 05 Nov 2016 03:53 UTC
Hi, John. Would you mind weighing in on this?
You might also take a look at Jeremy's pull request at
<https://github.com/scheme-requests-for-implementation/srfi-113/pull/9>.
Thanks.
Jeremy Steward <xxxxxx@thatgeoguy.ca> writes:
| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA256
|
| Hello all,
|
| Today I was perusing through the SRFI docs in an attempt to use `set-map`. To
| my surprise the argument order specified by the SRFI document were slightly
| backwards to the code. The problem is on lines 600 to 618 in srfi-impl.scm.
| You can find this online at
| https://github.com/scheme-requests-for-implementation/srfi-113/blob/master/sets
| /sets-impl.scm.
|
|
| The offending parts are as follows:
|
| (define (sob-map proc comparator sob)
| (let ((result (make-sob comparator (sob-multi? sob))))
| (hash-table-for-each
| (lambda (key value) (sob-increment! result (proc key) value))
| (sob-hash-table sob))
| result))
|
| (define (set-map comparator proc set)
| (check-set set)
| (sob-map comparator proc set))
|
| (define (bag-map comparator proc bag)
| (check-bag bag)
| (sob-map comparator proc bag))
|
| Basically, sob-map, which implements the actual mapping process over a set or
| a bag, has a different argument order than what set-map or bag-map uses. I
| think the intent (and IMO, the more pleasant) of the two argument orders is
| that it goes (set-map comparator proc set). Thus I propose that the argument
| order in sob-map be changed so that proc and comparator are swapped. This
| will put the implementation in line with the SRFI document, and shouldn't
| require publishing any errata (outside of documenting the fact that this bug
| existed, perhaps).
|
| I will submit a pull-request shortly on Github to reflect this change. For
| those who are using the CHICKEN Scheme egg for this SRFI, I have already
| applied and uploaded this change (can be reverted if a different solution is
| preferred).
|
| Regards,
| - --
| Jeremy Steward
| -----BEGIN PGP SIGNATURE-----
|
| iQIcBAEBCAAGBQJYGmGhAAoJEAJ1qwSKG/f21rMP/2Rn2o4syYFPHvY97kQN6EXk
| fgFR0jsGd0FoaodNQj/hrUJrF/gLN8JlK4DLoYwywUHBtlFctJg98ZxbNuCvV6hy
| m4WFpWjPT94fSXqEHrM7vrJXipHpGKkXz/7Gw964DTXQFnipwppJnibiebkYC8mP
| zDjAP+cYLkmunonm4h2yPl8LzkhBaKcWsEEiXsLS7sSIGcU4GTo8hA4j1N/r2mKu
| 2UcmKt43DJFziFLFMn6900I65WufSYKipNO1+xGcrTwPJR9F9y5aHGEDpZy2NBgM
| p3xmKnfbPABoGDvCc+Z79+99ZWMSDR6orjvfSMS0XEzg2TnFSn02U/kEjxFEn5xZ
| YFAxalsRL5DDlAA/8IsbPxG/ezw78hoqzFJpgOHJPLc/bsHGsa8IMViBxfpUO4D/
| Jp4cLiFNDGCfseLLiYQA3M/w2DcLVJ2u3OYIbVLpkLlouBn/9nmbH3qH3ZfK2cB/
| yMBlnco/5xlHZ4rPxRU/wabsQbZvw+/OmURJfUABPnojStPZRTKaOOwwWBmtF0wF
| 6mcQWyVL6GdxJYC3U9BoiKngZDx6rHDPl+TuoJbUz4Iy5ngBXyJhUmk/iMZSZmMo
| g5YlJTWjcSw/nNcHzVut0SwvWT4tHGcbLFniHUKm/VFPvueEZ8uuo69Vv/mYhNM4
| he8Es9QBqkzYZywcEVUc
| =HCHD
| -----END PGP SIGNATURE-----