Email list hosting service & mailing list manager

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