Arthur A. Gleckler scripsit:

> Counting anything from a fixed set of possibilities, e.g. the number of
> each type of error in a log file or the number of uses of each word in a
> lexicon in a body of documents.  It's a special case of other data
> structures, e.g. hash tables mapping items to integers, but it's good to
> have because it clearly expresses the programmer's intent and can be
> optimized.

I've merged this text into the SRFI.

> > If you add bags, a 'for-each-unique-element' procedure seems
> > essential - otherwise there seems to be absolutely no point.
>
> You're right.  There should also be a bag-unique-elements function, which
> returns the set of unique elements present in the particular bag.

Added as bag-for-each-unique and `bag->set` respectively.  I also added
`set->bag` for completeness, and resolved the issue about conversion.

> John, have you already done one of your comprehensive surveys of existing
> implementations?  I'd love to compare the proposal to what's already
> available.

There isn't much.  R6RS enumerations, Racket sets, and three Chicken
eggs: `sets`, `cis`, and `iset`.  Links are in the proposal, except
for `sets`, where there is no documentation: its module exports are
(make-empty-set set-copy set->list list->set set-add! set-remove! set-size
set-for-each set-has-member? set-is-subset? set-union! set-union
set-difference! set-difference set-intersection! set-intersection).

The new draft is at <http://ccil.org/~cowan/temp/srfi-113.html>.

--
Clear?  Huh!  Why a four-year-old child         John Cowan
could understand this report.  Run out          xxxxxx@ccil.org
and find me a four-year-old child.  I           http://www.ccil.org/~cowan
can't make head or tail out of it.
        --Rufus T. Firefly on government reports