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