Am Sa., 19. Sept. 2020 um 18:35 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> I think that the enum=?, enum<?, etc. forms should all require at
> least two enum arguments, unless there's some strong reason for
> keeping the zero- and one-argument cases.

Keeping the one-argument case for <? makes sense for "compatibility"
to the SRFI 1 lset interface.

Mathematically, the zero and one-argument cases make perfect sense, of course.

> I'm thinking out loud here, but would it make sense to provide an
> enum-set constructor, say enum-value->enums, which takes an enum-type
> t and a value v and returns an enum-set of all the enums in t with
> enum-value v?  The SRFI states "there is no way to find an enum by its
> value, since values need not be unique", and there is no
> enum-value->enum.  But this only means that such a "finder" isn't
> necessarily injective.  It's plausible and maybe even useful to map a
> value to an enum-set of results.
>
> Alternatively, or additionally, we may want to add enum-set-filter
> and friends.  Something equivalent to the above function could then
> be written:
>
>     (define (enum-value->enums type val)
>       (enum-set-filter (lambda (e) (equal? val (enum-value e)))
>                        (enum-type->enum-set type)))

The filter procedure is the more basic one, so IMHO if any, it should
be provided.