SRFI 146 draft 2 comments Sudarshan S Chawathe 25 Dec 2016 20:25 UTC

These comments refer to SRFI 146 Draft #2 (2016-12-20).  Most are
quite minor.

  * Is it correct that an implementation conforming to this SRFI
    cannot require comparators to provide both a comparison predicate
    and a hash function?

  * (minor) Tangential, editorial/procedural issue: Will the comments
    about SRFI 113 in the paragraph before the Index cause
    complications for SRFI finalization or R7RS inclusion?  In any
    case, they do seem like good ideas to me.

  * map-update/default and map-update!/default: Should the
    semantically equivalent expressions listed for both use
    map-ref/default instead of map-ref?

  * map-map: The argument comparator seems unused/unneeded based on
    the description.

  * (minor) In map-every?, formal argument is named 'set' instead of 'map'
    (technically OK, but confusing).

  * (minor) Above description of map-search!: The signature has
    map-search instead of map-search!.

  * map-ref: Should the SRFI guarantee that the success and failure
    procedures will be called in tail positions?  Would a similar
    requirement make sense for some other procedures? (I did not
    check.)

  * (minor) map-search: It was not clear to me whether an
	  implementation is permitted to return a newly allocated map when
	  the ignore continuation is invoked.  (I would guess not.)

  * (minor) map-update: The semantics when success (and failure) are
    omitted seem obvious but could be made more explicit.

  * (minor) In several places, this SRFI uses "comparison procedure"
    to mean (I think) what SRFI 128 calls "ordering procedure"
    (different from terminology of SRFI 114).

  * Is an implementation of this SRFI required to register
    map-comparator using comparator-register-default! of SRFI 128?  If
    so, I think it will be beneficial to state it explicitly.  If not,
    I don't understand how the behavior described just before
    "map-comparator" (just before the Implementation section) will
    work (other than implicitly modifying a SRFI 128 implementation to
    be aware of maps of this SRFI).

  * (very minor) The link to the sample implementation goes to just
    the .sld file instead of the top of the Github respository.

  * The very last test in srfi/146/test.sld of the sample
    implementation seems to me like it should fail:

	  (define map1 (make-map comparator 'a 1 'b 2 'c 3))
		...
	  (define map5 (make-map comparator 'a 1 'c 3))
    ...
	    (test-assert "<?: case 3"
	      (<? comparator map1 map5)))))

Regards,

-chaw