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