A proposed new approach to bounds vs. salt
John Cowan
(26 Dec 2015 02:12 UTC)
|
Re: A proposed new approach to bounds vs. salt taylanbayirli@xxxxxx (26 Dec 2015 14:00 UTC)
|
Re: A proposed new approach to bounds vs. salt
Alex Shinn
(30 Dec 2015 12:51 UTC)
|
Re: A proposed new approach to bounds vs. salt
John Cowan
(03 Jan 2016 22:26 UTC)
|
Re: A proposed new approach to bounds vs. salt
Shiro Kawai
(04 Jan 2016 02:08 UTC)
|
Re: A proposed new approach to bounds vs. salt
Alex Shinn
(07 Jan 2016 05:41 UTC)
|
Re: A proposed new approach to bounds vs. salt
Kevin Wortman
(15 Jan 2016 00:45 UTC)
|
Re: A proposed new approach to bounds vs. salt taylanbayirli@xxxxxx 26 Dec 2015 14:00 UTC
John Cowan <xxxxxx@mercury.ccil.org> writes: > Comments? I don't think I have any really interesting comments, but I have to say this feels like that kind of specification where I can see people in the future reading the standards shaking their heads saying "just what were they thinking". :-) An optional second argument whose "identity" changes depending on its type doesn't fare well in "WTFs per minute", though I'm not sure if I could come up with any concrete complaints. (And the "procedure or pair of procedures" argument to make-hashtable in SRFI-126 is admittedly similar.) Since this specification strictly extends the current SRFI-126 semantics of hash functions, it doesn't need to be mentioned in SRFI-126, correct? So I think I will refrain from sanctioning it there. I hope for SRFI-126 to be accepted for its own merits as a backwards compatible extension of R6RS hashtables. Further extensions that go beyond the current scope of SRFI-126 should again be weighted on their own merits. Happy Holidays! Taylan