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)
|
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