Open issues for SRFI 113
John Cowan
(04 Dec 2013 04:37 UTC)
|
Re: Open issues for SRFI 113
Kevin Wortman
(08 Dec 2013 04:35 UTC)
|
Re: Open issues for SRFI 113
John Cowan
(08 Dec 2013 18:05 UTC)
|
Re: Open issues for SRFI 113 John Cowan (08 Dec 2013 18:15 UTC)
|
Re: Open issues for SRFI 113
Kevin Wortman
(09 Dec 2013 00:43 UTC)
|
Re: Open issues for SRFI 113
John Cowan
(09 Dec 2013 08:04 UTC)
|
Re: Open issues for SRFI 113
Alex Shinn
(09 Dec 2013 08:16 UTC)
|
Re: Open issues for SRFI 113
John Cowan
(09 Dec 2013 15:59 UTC)
|
Re: Open issues for SRFI 113
Alex Shinn
(09 Dec 2013 00:39 UTC)
|
Re: Open issues for SRFI 113
John Cowan
(09 Dec 2013 17:13 UTC)
|
Re: Open issues for SRFI 113
Alex Shinn
(10 Dec 2013 01:18 UTC)
|
Re: Open issues for SRFI 113
John Cowan
(10 Dec 2013 21:35 UTC)
|
Re: Open issues for SRFI 113
Alex Shinn
(11 Dec 2013 00:55 UTC)
|
Re: Open issues for SRFI 113
John Cowan
(16 Dec 2013 07:12 UTC)
|
Scripsi: > I agree. My only reservation is that hash tables will have to support > naked equality predicates for backward compatibility with SRFI 69 and > R6RS. But I think we can allow them in that SRFI and deprecate them > instead of allowing them anywhere. Removed. I have added this paragraph: Implementations must support any comparator that provides both a comparison procedure and a hash function, as well as the comparators `eq-comparator`, `eqv-comparator`, and `equal-comparator`. Implementations may support other comparators, possibly with some degradation of performance. This permits an all-singing all-dancing implementation to use hash tables if a hash function is available, trees if a comparison procedure is available, and lists if neither is available. -- I suggest you solicit aid of my followers John Cowan or learn the difficult art of mud-breathing. xxxxxx@ccil.org --Great-Souled Sam http://www.ccil.org/~cowan