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?