Email list hosting service & mailing list manager

Re: New draft (#4) and last call for comments on SRFI 209: Enumerations and Enum Sets Marc Nieper-Wißkirchen (16 Nov 2020 08:07 UTC)

Re: New draft (#4) and last call for comments on SRFI 209: Enumerations and Enum Sets Marc Nieper-Wißkirchen 16 Nov 2020 08:07 UTC

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.

> I'm aware that R6RS has in mind a syntax-level approach here, which
> would require something other than syntax-rules.  But that doesn't
> seem to me to fit with SRFI 209's notion of enums, and John has
> specified define-enum differently.

In what sense it is specified differently so that it cannot support
expand-time elimination of any overhead compared to, say, C-style
defines of bit patterns?

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

PS I yet fail to see why SRFI 209 switched from symbols to abstract
enums, adding another layer on top of R6RS's enumerations. If we just
had symbols, one could still have `enum-value`, now in the form
`(enum-value ENUM-SET ENUM-SYM)`. And an O(1) version would be a macro
defined by an extended version of `define-enumeration`.

In the current form, SRFI 209 looks only superficially compatible to
the R6RS version.