Am Mo., 16. Nov. 2020 um 19:54 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>: > > 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. The creation of new enum-types is not time-critical, so (1) is not an issue. As for (2), `(color red)` should expand into an indexed vector lookup, which is very fast. There is no need for the `color` syntax to call `enum-name->enum` and loop over a table at runtime. > 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. As I mentioned above, creating enum-types at runtime is not a problem. Each library will only define a handful of them if any. > 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. The advantage of symbols is that they don't have to exported and imported by libraries. The type-checking is done by the constructor syntax. It looks that SRFI 209's abstract entities have the advantage of allowing an associated value, but this can be decoupled by maintaining lookup tables. > 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. 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. > > 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. My main point is probably that we shouldn't just add another incompatibility with R6RS, which helps no one. If the R6RS enumerations library is not sufficient, a compatible extension would be very much preferred. Which operations do you think cannot be provided on top of (rnrs enumerations)? Thanks for listening, Marc
