On 2020-11-16 09:07 +0100, Marc Nieper-Wißkirchen wrote:
> Am Mo., 16. Nov. 2020 um 08:46 Uhr schrieb Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz>:
> >
> > On 2020-11-16 08:12 +0100, Marc Nieper-Wißkirchen wrote:
> > > The original idea of the syntax `define-enumeration` is to have
> > > constructors of enumeration sets without runtime overhead. The current
> > > implementation produces constructor syntax that has quite some runtime
> > > overhead and doesn't encourage the use of enumerations in production
> > > code. Please provide fast versions (may need lower-level macros, e.g.
> > > syntax-case, to test for symbol equality).
> >
> > "Fast" is a somewhat vague requirement, and I'm not sure what
> > "quite some runtime overhead" refers to here.  The macros produced by
> > the current define-enum implementation shouldn't be any slower at
> > producing enum-sets/enums than the procedural versions--though perhaps
> > that's what you're objecting to.
>
> Exactly. The original idea of enum sets in R6RS was to have them
> represented as bit patterns, for example, and so that, say, `(color
> red blue green)` is performance-wise equivalent to a programming style
> that would use, say, #b00010011 instead.

Thanks for explaining.  I was wondering how define-enumeration's
constructor macro was supposed to create enum sets at expansion
time.

A similar representation should be possible with SRFI 209.  The sample
implementation uses a (type, mapping) tuple, but there's no reason why
the mapping couldn't be replaced by an exact integer or bitvector.  I'm
happy to try this out.

But that wouldn't allow us to write true "enum-set literals" (using
the term loosely) via define-enum.  (color red) can't just expand to
the symbol red; it must expand to the enum named red, which means
(1) creating a new enum-type, then (2) calling enum-name->enum.

A similar issue applies to the constructor macro: We still need to
create the new enum-type at runtime, even if a representation of the
new set (e.g. a literal exact integer) can be created at expansion
time.

It comes down, as you've noted, to the difference between R6RS's
idea of enums as just symbols, and SRFI 209's abstract structures.
We could do some things at expansion time using a different enum-set
representation and syntax-case (I think), but the SRFI 209 version
of define-enum will still have (negligible) runtime overhead.

> If this isn't possible, SRFI 209 would be an inferior solution to
> R6RS's enums (if `enum-value` isn't needed).

Is the lack of expansion-time enums and enum-sets such a cost?
In exchange, SRFI 209 provides operations on enums and enum types
which the R6RS can't easily provide.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"It is a syntax error to write FORTRAN while not wearing
a blue tie." --James Iry