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

[Jason Hemann <jason.hemann@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]