> But for a community project, having one blessed implementation and iterating quickly has proven to be the most successful model, in my opinion. That's not ho

> But for a community project, having one blessed implementation and iterating quickly has proven to be the most successful model, in my opinion. That's not how Scheme works, and I think it's important for both Scheme and PL research/design groups in general that they move the way they do. Each Scheme implementation is in fact its own language, with its own goals, focus, community, etc. E.g. Racket has very different goals (like PL research, education) from Stalin (aggressive optimization), Guile (ease of embedding), or Chicken ("real world" usage). Both the RnRS and SRFI processes are more like guidelines for the implementations to follow, to enable at least some of the code (usually libraries) to be portable. When you're writing your Scheme program, you're usually not targeting "R7RS" or "R5RS + SRFI-1" or whatnot; you're writing and running your program using Chicken, it's a Chicken program much more often than it is a R5RS program. If you later decide to port it to Racket, you will usually have much less porting work to do, but you'll still need to figure out how to do many of the mundane things omitted by the standard, like OS threads or FFI. It's much more useful to think of Scheme as a loosely-tied family of languages, pretty much the same way you can think of UNIX-like OS's. Your average UNIX will surely give you a /bin/sh and a printf and a malloc, but the really interesting stuff (like kqueue, io_uring, DTrace, etc) is why you choose to stick with one over the other, and what motivates different groups to experiment / innovate / contribute.