Am Sa., 31. Okt. 2020 um 20:02 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>: > > On 2020-10-31 09:36 +0100, Marc Nieper-Wißkirchen wrote: > > > I think the best bet is (enum-empty-set enum-type): added. > > > > Hmmm... that doesn't like the right thing to me. If the zero-element > > case need special treatment, something is flawed. > > > > Either let `enum-set` always take a type as its first argument (which > > can then be checked to assert the other arguments are of this type), > > or let `make-enum-type` return two values, the second one being the > > type-parameterized `enum-set`. > > Good point, the current design seems a little fishy. The obvious > solution is for both enum-set and list->enum-set to take a type > argument, but I'm finding the second approach interesting. Could > you elaborate on this? What would it mean for the existing ways > of constructing an enum-set? I mean that make-enum-type returns two values; the abstract type and a enum-set procedure that solely works for this type. The R6RS approach is here: http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-15.html#node_chap_14. There, there are no abstract types but each set knows the universe to which it belongs. It has the procedure "enum-set-constructor" applied to an enum set, which returns a procedure to construct more enumeration sets of the same type. Moreover, the define-enumeration syntax defines new enumeration types at runtime and binds a constructor macro to create enumeration sets at expand-time with type-checking at expand-time. By the way, is there a reason why SRFI 209 is not designed as a compatible extension of the R6RS library?
