|
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