On Wed, Dec 11, 2013 at 6:35 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
Alex Shinn scripsit:

> The canonical use case is SRFI 13.  Many of the procedures
> accept a char/char-set/procedure argument.  The only two
> SRFI 14 procedures needed to support that are `char-set?' and
> `char-set-contains?'.

Mmm.  What concerns me is that while this works for the "set or
individual" use case, you would need other subsets for other use
cases, and where do you stop?

Obviously there's no such thing as a perfect
factoring.  My rule of thumb for a library around
a type is to just provide the type itself (i.e. those
bindings generated by define-record-type).

For sets, the internals of the type are opaque so
it makes sense to provide just `set-contains?'
instead of the accessors.

For char-sets this works for SRFI 13, and is what
I do in the (chibi string) library.  It would also work
for e.g. a core regexp engine taking NFAs, with no
pre-defined notion of the SREs or PCREs that
generate them.

Sets arguments in APIs are also commonly used
as whitelists and blacklists, for which all you need
is `set-contains?'.  If non-polymorphic, you don't
even need `set?' but it's good to provide.

The counter-argument is that if you need to generate
sets to use a library anyway, then the caller needs
to pull in the full set library regardless.  However,
there are many cases where you can use the library
without constructing any sets:

  1. you're not using any of the procedures that
      take set parameters
  2. the set parameters are optional or polymorphic,
      e.g. allowing #f for the empty set or allowing
      either lists or sets
  3. you're only passing through sets, not generating
      any on your own
  4. you have pre-generated sets, possibly via an
      implementation-specific extension such as a
      serialization library

To help with the case of optional arguments you
could also include an empty-set constructor, and
I would not object to this.

-- 
Alex