Email list hosting service & mailing list manager

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