Email list hosting service & mailing list manager

Enum comparisons and value-lookup Wolfgang Corcoran-Mathe (19 Sep 2020 16:35 UTC)
Re: Enum comparisons and value-lookup Marc Nieper-Wißkirchen (19 Sep 2020 17:34 UTC)
Re: Enum comparisons and value-lookup Wolfgang Corcoran-Mathe (19 Sep 2020 17:55 UTC)
Re: Enum comparisons and value-lookup Marc Nieper-Wißkirchen (19 Sep 2020 17:59 UTC)
Re: Enum comparisons and value-lookup Wolfgang Corcoran-Mathe (19 Sep 2020 18:00 UTC)
Re: Enum comparisons and value-lookup John Cowan (19 Sep 2020 22:12 UTC)
Re: Enum comparisons and value-lookup Wolfgang Corcoran-Mathe (20 Sep 2020 02:46 UTC)
Re: Enum comparisons and value-lookup John Cowan (20 Sep 2020 02:51 UTC)

Enum comparisons and value-lookup Wolfgang Corcoran-Mathe 19 Sep 2020 16:35 UTC

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.

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)))

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Abstraction lies at the heart of all programming languages."
--Greg Michaelson