Remaining issues Wolfgang Corcoran-Mathe (30 Oct 2020 18:04 UTC)
Re: Remaining issues John Cowan (31 Oct 2020 01:30 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:49 UTC)
Re: Remaining issues Wolfgang Corcoran-Mathe (06 Nov 2020 01:03 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 Wolfgang Corcoran-Mathe 31 Oct 2020 19:02 UTC

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?

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"For good or ill, when I went off to grad school, I studied
linguistics, so the only computer language I used there was LISP.
It was my own personal McCarthy era." --Larry Wall