Without a syntax-case (or some other procedural macro) implementation,
the `define-enum(eration)` macros are rather suboptimal and not in a
form that I would call production-ready. So to demonstrate how they
should be implemented, I would like to strongly suggest to add the
syntax-case implementation.

But I agree with John that it should behind a cond-expand barrier so
that the implementation also runs on a bare R7RS (small) system
(modulo SRFI 151). You can use:

(or (library (chibi syntax-case)) (library (rnrs syntax-case))
(library (srfi 211 syntax-case)))

(Others may know more library names that could be tested against.)

Am Di., 17. Nov. 2020 um 19:26 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> I would say not to use syntax-case unless it is behind a cond-expand barrier of some sort.
>
> On Tue, Nov 17, 2020 at 1:25 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>>
>> On 2020-11-16 20:36 +0100, Marc Nieper-Wißkirchen wrote:
>> > Yes, a bit vector representation seems like the best solution, and
>> > fast syntax-case macros so that implementers can just copy the sample
>> > implementations and their users don't have to worry about performance.
>>
>> Looks good to me.  This will take a little more time to implement and
>> test sufficiently.
>>
>> I've opted to use integer bitmaps rather than bitvectors in the sample
>> implementation, to avoid the (rather large) SRFI 178 dependency.  This
>> should be extremely efficient for small sets, which probably describes
>> 99% of the use-cases for enum-sets.
>>
>> The remaining question: Shall we use syntax-case in the sample
>> implementation?
>>
>> --
>> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>>
>> "Computer science is no more about computers than astronomy is
>> about telescopes." --pseudo-Dijkstra