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

On Mon, Nov 23, 2020 at 7:36 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:

Unless John wants to specify the complexity requirements of enum sets
in more details, I don't think such a recommendation should be added.

I don't want to do that, so I agree that there's no need for such a recommendation.

<exaggeration warning>

There is no complexity requirement that says that vectors must not be implemented as linked lists. Nevertheless, there is some recommendation of their uses (vs. lists) in the R7RS (small). Programmers can expect that their favorite implementation implements vectors in a way that makes access roughly as fast as if the vectors are implementated as linear arrays on the hardware.

</exaggeration warning>

A quality implementation of SRFI 209 will use a bitmap representation. Actually, this fast representation is one raison d'être for enum sets.

The recommendation to use enum sets instead of single enum values or symbols whenever possible is also important for the design of APIs so it should be stated somewhere. Let us take `string-join` from SRFI 152, for example. It has a GRAMMAR argument, which can be a symbol out of a set of four. If SRFI 152 (or some successor) is designed with SRFI 209 in mind, it makes a lot of sense to turn this symbol argument into an enum argument (which can be dynamically type-checked).  But there are two options: Either the argument becomes a single enum (symbol) or it becomes an enum set (of a single element). The latter would be the preferred form with the recommendation and would allow implementations as fast as if the options were given by raw numbers. Moreover, it would allow the compiler to inline code. (The latter would probably be harder if dynamically constructed enum objects would be passed.)

I have similar objections with regard to define-enum's supposed "early
error detection". This doesn't make sense unless the macro is actually
required to raise errors at expansion-time, which it currently isn't.

+1

Do you actually want to forbid early error detection or make this optional? If early error detection is allowed, one should expect that good implementations detect the error early (even if just for the sake of a superior debugging experience). So a coding style by the programmer that enables early error detection (when implemented by the implementation) is very much preferable (and could be hinted at in this SRFI).

Personally I think, as soon as we have some form of procedural macro in R7RS (large), it doesn't make sense *not* to require that errors like these are already detected at expansion time. (We are not programming in C, after all.) This (the domain of syntax violations) is something that R6RS go right and if R7RS small+large are intended to function as possible successors, they should improve on it, and not make it worse.

If all hings on whether we have procedural macros, I can only repeat my opinion that we should set up the basics first.

Marc