3 ms·

> Chicken opted to stick with RSR5 for a long time [...] implementing RSR7 [...] Is there something else I'm missing out on? As an outsider (I admire Scheme, b

by xscott 5y ago

> Chicken opted to stick with RSR5 for a long time [...] implementing RSR7 [...] Is there something else I'm missing out on? As an outsider (I admire Scheme, but don't really use it day to day), I got the impression R6RS was very divisive. Some people really wanted to make a "batteries included" revision to the standard so that Scheme could be used the way Python/Java is. However, this meant that the standard was prohibitively complicated for small/research implementations, and it lost some of the R5RS elegance and philosophy. In response, R7RS tried to tie things back together by having two versions (I think they call them Small and Large), where Small is a subset of Large, and both pretty much disregard R6RS. Anyways, I believe Chicken was firmly in the "disagrees with the design of R6RS" camp. And for what it's worth, I think the decision to create the name "Racket" (and associated design changes) also came about because of this schism. Even though they have an R6RS language/implementation, I don't believe the Racket language conforms to any of the RnRS standards. I'm certain someone here can do the history more justice if they wanted.

bjoli 5y ago
I think Göran Weinholt summarises it well, but from a pro-r6rs perspective: https://weinholt.se/articles/r7rs-vs-r6rs/ https://weinholt.se/articles/r7rs-vs-r6rs/
johncowan 5y ago
A few notes: 1) R6RS isn't really all that "batteries included", though it has some really basic features like hash tables that weren't in R5RS (but were in most Schemes anyway). The emphasis was on portability and safety. All R6RS implementations, if they don't have bugs, behave the same as all the rest at least as far as the standard extends, and the standard defines pretty closely what arguments are accepted, what values are returned, and what exceptions are signaled (the last was controversial even within the closed R6RS committee). What wasn't considered was interoperability with common practice in other Schemes. In pursuit of this, R7RS favors interoperability over portability: the standard is less constraining, which makes it easier to integrate with existing Schemes. So R6RS hashtables (things that can be hashted, eh?) are incompatible at the procedure name level and some of the semantics with almost everybody else's hash tables. R7RS-large made them as compatible as possible. (Granted, we took more time to think about it.) R7RS-large also favors big-enough-ism over minimalism within each library, though it won't have as many libraries as people from other languages might like. 2) The current plan for R7RS-large will provide many parts of R6RS (a little bit R7RS-ified in some cases), provided they are voted in by the R7RS-large working group. 3) The rename of PLT Scheme to Racket had nothing to do with RnRS. PLT supported R6RS before and supports it R6RS today, though its use is not particularly encouraged by the Racketeers, who want you to use their own main dialect of Scheme, also called Racket. The change had more to do with PLT's multilingual capabilities: it supports many dialects of Scheme plus completely non-Scheme languages like Python and Algol 60, and it would be straightforward, if tedious, to provide Fortran, Cobol, and even C. In addition, PLT had no real link with the various university programming-language theory groups any more. On participating in the Working Group: Any Schemer can join the Working Group at any time: subscribe to scheme-reports-wg2@googlegroups.com and listen for CFVs. (If you have never voted before on anything Scheme-related, send a message after you subscribe giving your name, a little bit about yourself, and a bit more about your interest in Scheme. This is primarily to discourage sockpuppets.) There are long spells of inactivity followed by intense discussion when a new ballot comes up. All discussions and votes are public. Behind-the-scenes work is also done in public using the SRFI process at srfi.schemers.org, which produces specs and sample
- xscott 5y ago
  Thank you for the corrections.

by xscott 5y ago

bjoli 5y ago

I think Göran Weinholt summarises it well, but from a pro-r6rs perspective: https://weinholt.se/articles/r7rs-vs-r6rs/ https://weinholt.se/articles/r7rs-vs-r6rs/

johncowan 5y ago

A few notes: 1) R6RS isn't really all that "batteries included", though it has some really basic features like hash tables that weren't in R5RS (but were in most Schemes anyway). The emphasis was on portability and safety. All R6RS implementations, if they don't have bugs, behave the same as all the rest at least as far as the standard extends, and the standard defines pretty closely what arguments are accepted, what values are returned, and what exceptions are signaled (the last was controversial even within the closed R6RS committee). What wasn't considered was interoperability with common practice in other Schemes. In pursuit of this, R7RS favors interoperability over portability: the standard is less constraining, which makes it easier to integrate with existing Schemes. So R6RS hashtables (things that can be hashted, eh?) are incompatible at the procedure name level and some of the semantics with almost everybody else's hash tables. R7RS-large made them as compatible as possible. (Granted, we took more time to think about it.) R7RS-large also favors big-enough-ism over minimalism within each library, though it won't have as many libraries as people from other languages might like. 2) The current plan for R7RS-large will provide many parts of R6RS (a little bit R7RS-ified in some cases), provided they are voted in by the R7RS-large working group. 3) The rename of PLT Scheme to Racket had nothing to do with RnRS. PLT supported R6RS before and supports it R6RS today, though its use is not particularly encouraged by the Racketeers, who want you to use their own main dialect of Scheme, also called Racket. The change had more to do with PLT's multilingual capabilities: it supports many dialects of Scheme plus completely non-Scheme languages like Python and Algol 60, and it would be straightforward, if tedious, to provide Fortran, Cobol, and even C. In addition, PLT had no real link with the various university programming-language theory groups any more. On participating in the Working Group: Any Schemer can join the Working Group at any time: subscribe to scheme-reports-wg2@googlegroups.com and listen for CFVs. (If you have never voted before on anything Scheme-related, send a message after you subscribe giving your name, a little bit about yourself, and a bit more about your interest in Scheme. This is primarily to discourage sockpuppets.) There are long spells of inactivity followed by intense discussion when a new ballot comes up. All discussions and votes are public. Behind-the-scenes work is also done in public using the SRFI process at srfi.schemers.org, which produces specs and sample

xscott 5y ago
Thank you for the corrections.