Deprecating and replacing SRFI 114
John Cowan
(22 Oct 2015 23:44 UTC)
|
Re: Deprecating and replacing SRFI 114
Shiro Kawai
(23 Oct 2015 02:50 UTC)
|
Re: Deprecating and replacing SRFI 114
John Cowan
(23 Oct 2015 03:49 UTC)
|
Re: Deprecating and replacing SRFI 114
Kevin Wortman
(28 Oct 2015 23:41 UTC)
|
Re: Deprecating and replacing SRFI 114
John Cowan
(29 Oct 2015 01:51 UTC)
|
Re: Deprecating and replacing SRFI 114
Shiro Kawai
(29 Oct 2015 02:36 UTC)
|
Re: Deprecating and replacing SRFI 114 John Cowan (29 Oct 2015 12:45 UTC)
|
Re: Deprecating and replacing SRFI 114 John Cowan 29 Oct 2015 12:45 UTC
Shiro Kawai scripsit: > Could srfi-128 "basic" comparators, to be the basis of various > containers, and a separate utility library that contains other fluffs? Absolutely, though I myself don't wish to undertake it at this point. > If we don't have the revisions such as in hash function signature, we > might even be able to keep srfi-114 as the optional enhanced > comparator library while srfi-128 being essential base. I think that would be a mistake, though of course I can't prevent it. I believe the use of an ordering predicate is fundamentally more aligned with the Scheme way of doing things than a comparison predicate. I originally proposed some proto-comparators that only did equality; Mike Sperber pointed me to SRFI 87, and I ended up incorporating everything in it rather uncritically. However, it should be easy to rewrite SRFI 114 on the basis of SRFI 128. > I did implement the basic comparators as Gauche built-in so that other > built-in containers can use it, and left other utility stuff into a > separate library. Good. -- John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org They tried to pierce your heart with a Morgul-knife that remains in the wound. If they had succeeded, you would become a wraith under the domination of the Dark Lord. --Gandalf