John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> I settled with hashtable-prune! after all.  I find it nice enough.
>
> How about -preserve! (for -filter!) and -discard! (for -remove!)?
> I haven't done this yet.

I find those names somewhat strange, and don't think we absolutely need
to have the two variants.  Negation by hand is trivial.

> What is it you have against SRFI-114?  If you don't like all the
> procedures, it could be partitioned into two libraries.

I could give a better critique if I also had experience working with
something like comparators instead of only having experience working
without anything like them, but from looking at the spec it feels like
it's trying too hard to abstract something where no clear and natural
abstraction exists.  For sorting you only need a comparison procedure,
the type-check being implicit in it.  For hash tables you only need hash
and equivalence functions, the type check being implicit in the hash
function.  A tree again requires a comparison.  Yes, bundling some
together allows you to implement some generic interfaces where the
underlying data structure might be a hash table OR a tree (or something
else entirely, theoretically), but in the rare case you want such an
abstract interface you can cook up something sufficient on the spot (or
use SRFI-67 or 114 of course, but locally).  For a simple set library
it's just fine to leak the detail that it's implemented via hash tables.

On further thought, it might be very good for larger programs to have a
generic set library whose implementation can switch between hash tables
and binary trees (or more) transparently, so maybe SRFI-113 with
SRFI-114 is good after all, but SRFI-114 shouldn't be used for the hell
of it where it doesn't bring any clear advantage; it will just obfuscate
thinking, be an unnecessary layer of indirection, etc.

I wish I'd had participated in SRFI-113's discussion by the way.  There
are a couple "WTF" operations there.  (set-delete-all set list) is just
(apply set-delete set list).  List->set! seems very strange...  Anyway,
it's finalized.

Taylan