1. 40
  1.  

  2. 14

    This debate is exactly why Racket has been successful, in my opinion. Starting from R6RS and effectively forking scheme resulted in a nice, practical language to use while leaving the controversy behind. Racket can support scheme standards with #lang so nothing is lost…

    Even still, I find myself wishing for a small, fast, r7rs scheme…and get frustrated when there are non portable break hygiene macro systems… wish we could settle on explicit renaming, something far simpler to implement, on which pattern based macros could be built on top of, portably.

    1. 8

      Author here.

      1. 3

        Thanks for the post it really helped me understand what was going on as I’ve stopped following the reports during R5RS and never caught up with R6RS and R7RS.

        1. 3

          Excellent post! Thanks for writing it. Just wanted to recommend that you should mention you’re specifically talking about R7RS-small earlier in the post. Things might get a bit confusing when R7RS-large comes out.

          1. 3

            Thank you, that’s a good suggestion.

          2. 3

            Do you think R7RS-Large will be a game changer? Or will R6RS continued to be seen as “a full solution” you think?

            1. 3

              R7RS-large is IIUC larger than R6RS, already. And yes, according to me it is a game changer. Sadly C FFI is not part of it.

              1. 2

                For the R6RS implementations that have a built-in FFI, a portable C FFI is available in r6rs-pffi (as you of course know). In what sense is R7RS-large a game changer, do you think?

                1. 1

                  R7RS-large promotes good coding practice with hygenic macros, a better exception story, and the inclusion of several foundational libraries like SRFI-41, SRFI-128, generators and accumulators. I miss CFFI, SRFI-145 assume as a type hint facility, and some network libraries including HTTP and websocket. Also a better port story would be nicer. I guess the predicate approach to exceptions does not please every one but I like it, so far.

                  I am good with the fact that there is no OOP, but I might change my mind, even when programming GUI I do not use OOP anymore.

              2. 1

                It would be better if someone else answers about R7RS-large; I’m out of touch with the standardization effort and haven’t even checked what the scope and the vision is. “Large” as such is not so appealing to me. But what I think will be a game changer is if we start to get more standards like SRFI 170 (POSIX API). R7RS-large is pushing for more things like this, which is really good. I doubt that R6RS will be supplanted by R7RS-large because there are even those who still prefer R4RS and R5RS.

                1. 1

                  If large isn’t appealing to you, is that not the point of R7RS-small?

                  1. 2

                    Exactly. The way I understand it is that R7RS-small and R7RS-large were set up in a way that those who like small would have R7RS-small and those who like large would have R7RS-large. This way both parts of the community would be pleased by R7RS. I disagree with the assumptions behind that setup and I don’t think it will have the intended effect, because that is not where the disagreement really was. I don’t think we have a part of the community that wants a large language and a different part that wants a small one. There is more to it than large or small, and even those are relative concepts.

                    1. 2

                      It seems pretty clear to me that the community is split down the middle between people that want something like R6RS and people that want something like R5RS. I’d also suggest that’s the received wisdom in the community. Why is it that you disagree?

                      1. 1

                        I don’t disagree that some prefer R6RS-alike and some R5RS-alike. But rather I think that R7RS-large and R7RS-small, taken together, will not result in an R6RS-alike and an R5RS-alike. It will be something new and different than either of those two camps. And that was not the intended result, AFAIK.

                        (And please don’t take any of this as criticism of R7RS-large, it appears to have good effects so far, and I think we all need more respect and understanding of each other’s perspectives on Scheme).

                      2. 1

                        Where do you think the disagreement was?

                        1. 1

                          The disagreement should’ve been summed up in the blog post, or maybe I misunderstood your question?

              3. 1

                This is good. I’ve only written some R5RS for university, I didn’t even know about this R6RS vs R7RS thing. However, I take slight issue with this conclusion to the undefined behavior part:

                R7RS side: Safety is not a desirable language feature. R6RS side: Safety is an essential language feature.

                Both sides presumably think safety is a desirable language feature, but one side might think the costs to adding more safety aren’t worth it.

                1. 2

                  but one side might think the costs to adding more safety aren’t worth it.

                  One side thinks the costs of requiring strict safety of an implementation is not worth the freedom to allow implementations to be unsafe in certain situations. Most practical implementations will be safe by default, but might allow compiler switches to enable unsafe optimizations. It’s nice to know that this kind of option will still be standards compliant. And of course there may be implementations which don’t think the costs of checking is worth it (think systems like BONES), and those will be standards compliant too.

                2. 1

                  “Finally, a caveat for this whole article is that it applies to R7RS-small vs R6RS. Much might change with R7RS-large.”

                  Isn’t R7RS-small supposed to be an improvement to R5RS that ignores the whole R6RS political mess?