Email list hosting service & mailing list manager

Remaining issues Wolfgang Corcoran-Mathe (30 Oct 2020 18:04 UTC)
Re: Remaining issues John Cowan (31 Oct 2020 01:29 UTC)
Re: Remaining issues Arthur A. Gleckler (31 Oct 2020 01:37 UTC)
Re: Remaining issues John Cowan (31 Oct 2020 01:50 UTC)
Re: Remaining issues Wolfgang Corcoran-Mathe (31 Oct 2020 06:16 UTC)
Re: Remaining issues Marc Nieper-Wißkirchen (31 Oct 2020 08:36 UTC)
Re: Remaining issues Wolfgang Corcoran-Mathe (31 Oct 2020 19:02 UTC)
Re: Remaining issues Marc Nieper-Wißkirchen (31 Oct 2020 19:48 UTC)
Re: Remaining issues Wolfgang Corcoran-Mathe (06 Nov 2020 01:02 UTC)
Re: Remaining issues John Cowan (15 Nov 2020 02:06 UTC)
Re: Remaining issues Arthur A. Gleckler (15 Nov 2020 02:31 UTC)
Re: Remaining issues John Cowan (15 Nov 2020 02:36 UTC)
Re: Remaining issues Arthur A. Gleckler (15 Nov 2020 02:53 UTC)
Re: Remaining issues Wolfgang Corcoran-Mathe (15 Nov 2020 02:57 UTC)

Re: Remaining issues Marc Nieper-Wißkirchen 31 Oct 2020 19:48 UTC

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?