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)
|
Re: Enum comparisons and value-lookup Wolfgang Corcoran-Mathe 19 Sep 2020 17:55 UTC
On 2020-09-19 19:33 +0200, Marc Nieper-Wißkirchen wrote: > 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. That makes sense to me. I see that SRFI 113 also keeps the one-argument case. > > 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 filter procedure is the more basic one, so IMHO if any, it should > be provided. OK, yes. It is more fundamental, and thus preferable to specific filters. The only advantage of providing an explicit enum-value->enum-set procedure is that it might be a slight efficiency win. -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> "The composer makes plans, music laughs." --Morton Feldman