SRFI 125 draft 8 comments Sudarshan S Chawathe (07 May 2016 21:13 UTC)
Re: SRFI 125 draft 8 comments Sudarshan S Chawathe (07 May 2016 21:38 UTC)
Re: SRFI 125 draft 8 comments Per Bothner (07 May 2016 22:12 UTC)
Re: SRFI 125 draft 8 comments John Cowan (08 May 2016 02:17 UTC)
Re: SRFI 125 draft 8 comments John Cowan (08 May 2016 17:48 UTC)
Re: SRFI 125 draft 8 comments taylanbayirli@xxxxxx (09 May 2016 07:03 UTC)
Re: SRFI 125 draft 8 comments John Cowan (09 May 2016 20:13 UTC)
Re: SRFI 125 draft 8 comments Arthur A. Gleckler (09 May 2016 20:25 UTC)
Re: SRFI 125 draft 8 comments taylanbayirli@xxxxxx (12 May 2016 15:49 UTC)

SRFI 125 draft 8 comments Sudarshan S Chawathe 07 May 2016 21:13 UTC

Here are some comments on Draft #8 (2016-05-06) of SRFI 125.  They are
all quite minor.

  * Constructors section, 2nd para: I believe the intent is to
    indicate that an implementation may use a hash function different
    from the one specified (within the comparator or separately in the
    deprecated form) when the equality predicate provided (also within
    the comparator or separately in the deprecated form) is a
    refinement of equal?.  If this is correct, then the wording
    "implementation-dependent hash function instead of the
    equality-predicate" seems confusing to me.

  * hash-table: Is something like the following an error? If not, which
    value is associated with 1?

      (hash-table (make-eqv-comparator) 1 10 1 20)

  * hash-table-set!: Is the order in which the hash table is
    repeatedly mutated restricted?  In particular, what is the
    behavior when some key is repeated in the arguments (or is that
    disallowed)?  The convention used for alist->hash-table would
    suggest a result consistent with a right-to-left repeated
    mutation, but I'm unsure.

  * hash-table-pop!: The sample implementation expects an additional
    (failure) argument.  Also, shouldn't there be a performance
    guarantee here similar to those in earlier procedures?

  * hash-table-map: The sample implementation expects an additional
    (merger) argument.

  * Implementation section: typo "any any"

  * (somewhat tangential and very minor) The "Last modified" tag at the
    very end of the Web page seems like it doesn't get updated (still
    shows Aug 2015).  It just gave me a fright when I got to it,
    thinking I may have wasted time reading a long obsolete version in
    detail.

Regards,

-chaw