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