Re: GRFI [was: The Guile junk drawer and a C plea]

[Jason Hemann]

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 <lassi@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.