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)

Re: Open issues for SRFI 113 Kevin Wortman 08 Dec 2013 04:35 UTC

> 8. Should we switch to unique enum objects rather than symbols?
> Symbols are all distinct from one another, and are convenient to use,
> but it's not possible to ask which enum-set a symbol belongs to, for it
> may belong to more than one.

I think symbols are best.

> 12. Should we stick to just comparators, or also allow equality
> predicates?  SRFI 114 provides comparators for `eq?`, `eqv?`, `equal?`,
> `string=?`, and `string-ci=?`, which are the Big Five.  Hash tables need
> to accept equality predicates for backward compatibility, but there is
> no real compatibility issue for sets.

I think it should be comparators only. Otherwise there is an implicit
union type of comparator-or-equality-predicate. Code that depends on
this SRFI, or mimics it, would also need to deal with the
comparator-or-equality-predicate type, so code handling that concern
would be scattered all over the place. Creating a comparator is easy so
I think it's reasonable to expect client code to do that.

> 13. Should we switch to six libraries (sets, bags, integer sets,
> character sets, enum sets, and set-bag conversion), or stick with a single
> library? (This is not about dividing the SRFI itself.)  The only reason
> to do this would be to minimize namespace pollution and load space:
> if you don't need bags or charsets, you wouldn't have to have them.
> On the other hand, the whole package is only about 2 KLOC.

In my use cases the time and effort that it takes programmers to find
and import multiple fine-grained libraries is far costlier than the time
it might take a Scheme environment to load a single coarse one, so I say
stick with one library.

> 14. Should we add a cursor API similar to SRFI 14's?  This would allow
> stepping through the elements in a fixed order.  It wouldn't make much
> sense for general sets or bags, but might be handy for character sets
> (via SRFI 14), integer sets, and enum sets.

This can be deceptively complex with mutable structures, since all the
interactions between mutative operations and pre-existing cursors need
to be defined precisely.

If we do go down this route I would advocate using streams (lazy
sequences) for this purpose rather than inventing a new cursor API.

Presently one could iterate through a set by converting it to a list and
using established list iteration methods, admittedly with O(n) space
overhead. Are there use cases where this would be inadequate?

Kevin Wortman