Email list hosting service & mailing list manager

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)

Re: SRFI 125 draft 8 comments John Cowan 08 May 2016 17:48 UTC

Sudarshan S Chawathe scripsit:

>   * 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.

Changed to:

As mentioned above, implementations are free to use an appropriate
implementation-dependent hash function instead of the
specified hash function, provided that the specified equality predicate
is a refinement of the <code>equal?</code> predicate.
This applies whether the hash function and equality predicate are passed
as separate arguments or packaged up into a constructor.

>   * 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)

It's an error, and I added text to say so.

>   * 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.

The intended implication is that the rightmost argument wins.  In
alist->hashtable, the leftmost value of a key wins, because alists
are searched left to right.  I've added clarifying language.

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

The implementation has not been updated to the new specification.

>   * Implementation section: typo "any any"

Fixed.

>   * (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.

I've updated it, but the date in the git repository is a more reliable
source of truth.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman