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