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: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 06 Nov 2020 01:02 UTC

On 2020-10-31 20:48 +0100, Marc Nieper-Wißkirchen wrote:
> By the way, is there a reason why SRFI 209 is not designed as a
> compatible extension of the R6RS library?

How would you suggest this work?  I was discussing the idea with John
on the #scheme Freenode channel and John suggested three possible
ways of combining SRFI 209 and (r6rs enums):

(a) Ensure that (r6rs enums) can be implemented on top of SRFI 209.

(b) Do the above and provide a sample SRFI-209-based implementation
of (r6rs enums).

(c) Add all of the (rnrs enums) forms to SRFI 209, making this a
proper superset.

(I'm paraphrasing, so apologies to John if I've misinterpreted
anything.)

If it's possible (and I believe it is) to make this SRFI compatible
with the R6RS library without too much redesign, I'm all for it.

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

"Scientists must be optimists at heart, in order to block out the
incessant chorus of those who say 'It cannot be done.'"
--Academician Prokhor Zakharov