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