Am Di., 24. Nov. 2020 um 20:40 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> There remains the question of urging the use of (singleton) enum-sets rather than enums.  The idea of using enum-sets, which are strongly typed (in the sense of an enum-type) rather than bare enums makes sense if enums are symbols, as in R6RS.  When they are strongly typed objects (unique to a single enum-set) that doesn't arise.
>
> In addition, the question of efficiency is quite unclear.  The enum equality function is identity (i.e. eqv?), whereas the enum-set equality function requires unwrapping the objects and then the more complex = test, where the time taken is proportional to the size of the enum type.

As long as enumeration sets are small (as they will probably be in
most use cases), an enum set will more or less be represented by a
processor word, for which tests on equality or inclusion (of bit
patterns) are handled by single machine instructions.

Testing two enums (or enum symbols in the case of R6RS) for equality
is, of course, equally fast, but other tests (like whether an enum is
in a set) may not. This is definitely true for R6RS enums.

It is also a question of the economy: If a library offers an interface
that takes a number of enums for configuration, it may not want to
export all single enum objects (polluting the namespace of importing
clients). Instead, if its interface accepts enum sets, it is enough to
export the single constructor syntax coming from `define-enum`, which
creates enum sets at expand time out of symbols.

Moreover, this has the advantage that the library can later extend its
API (by offering more configuration enums) without having to increase
the number of exports (which can lead to unexpected name clashes).

So, I don't see a use case where it instead makes more sense to have
single enums (vs singleton enum sets) as arguments (unless we are
talking about enum sets with, say, more than 128 enums).

> On Tue, Nov 24, 2020 at 6:28 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> John promised to explain in the rationale why the extra complications of SRFI 209 (enum types, enum objects, associated values) compared with the quite basic (rnrs enumerations) are actually a good thing.
>
>
>  New text:
>
> R6RS enums ameliorate these disadvantages by providing "type-safe" sets, which can be stored more efficiently than general lists, possibly as integers. However, neither enum types nor enum objects are exposed, only enum names and enum sets. This means that R6RS cannot have a procedure that takes an enum-type and returns the enum of the type whose ordinal number is n, nor a procedure that takes an existing enum-type and creates an enum-set containing specified enums from it. Instead, it must use procedures that return a quasi-curried procedure for performing these operations on a specified enum-type. The nearest equivalent to an enum object in the sense of this SRFI is a singleton enum set. To perform an efficient test of enum set membership, it is necessary to use such a singleton, and comparing two such sets for equality involves = rather than eqv?.

I don't understand the point about the enum type. In R6RS, it is the
full enum set (the "universe") that is representing the type. So, R6RS
could have a procedure that takes an enum-set and returns the enum of
the type of that set whose ordinal number is n, etc.