Was the GRFI proposal intended to work around the difficulties posed by a hard-fork of Guile (a la Python 2 vs. 3)? [as discussed in prior thread]
It seems to me that major breaking changes bring lots of downside, and I’m not sure the immediate benefits would outweigh them. I think of the SRFI process as soft-standardization across different implementations, though. So, I’m not sure I follow. Absent some major language version split, what the GRFI process would be _for_? Best, [PS: You—yes you—should consider writing up and submitting a paper to the upcoming Scheme Workshop https://icfp24.sigplan.org/home/scheme-2024 (July 18 deadline)] Jason Hemann Assistant Professor of Computer Science Seton Hall University On Jun 29, 2024 at 15:14 -0400, Lassi Kortela <la...@lassi.io>, wrote: > > How about a GRFI site to deal with proposals to Guile? > > I advise against starting a GRFI unless you can find plausible ways to > solve the known problems with the SRFI process. In case you can solve > these difficult problems which many smart people have failed to solve, > perhaps the new process could be somehow merged with SRFI itself. > > Empirically, it seems that most schemers will not watch many inboxes. > Each separate design process will add its own inbox with subtly > different rules and customs. That's non-trivial cognitive load. >
