5 ms·

In case you are a casual observer or are new to Scheme and are wondering why this might be particularly important to the language, wikipedia explains: "The R6

In case you are a casual observer or are new to Scheme and are wondering why this might be particularly important to the language, wikipedia explains: "The R6RS standard has caused controversy because it is seen to have departed from the minimalist philosophy [of scheme]. In August 2009, the Scheme Steering Committee ... announced its intention to recommend splitting Scheme into two languages: a large modern programming language for programmers, and a subset of the large version retaining the minimalism praised by educators and casual implementors;"[1] Perhaps the history of Scheme standardization itself has something to teach us about the challenges and rewards of openly balancing a wide range of interests and agendas over the long term? [1] https://en.wikipedia.org/wiki/Scheme_(programming_language)#R7RS https://en.wikipedia.org/wiki/Scheme_(programming_language)#...

hvs 10y ago
Any popular language that is going through a standardization process can teach us a lot. As opposed to languages that have "benevolent dictators" (Ruby, Python, etc), languages like Common Lisp, Scheme, C++ have all gone through standardization processes that often leave a lot to be desired. Unfortunately, that lesson usually learned is "don't do it", but I'm hoping that Scheme has righted the ship a bit and R7RS will be able to balance the goals of multiple diverse groups. The last thing we need is another Common Lisp.
- chm 10y ago
  It's trivial to run R5RS in DrRacket, for example, or other Scheme implementations as well. So it shouldn't really be a problem if R7RS becomes bloated, as you can stay on R5.
  - hga 10y ago
    Well, note that this is about R7RS-large; R7RS-small is "a 'small' language, suitable for educators, researchers, and users of embedded languages, focused on R5RS compatibility" (http://trac.sacrideo.us/wg/wiki/R7RSHomePage http://trac.sacrideo.us/wg/wiki/R7RSHomePage see also http://www.scheme-reports.org/ http://www.scheme-reports.org/), its spirit is R5RS cleaned up and with a library feature to allow R7RS-large to be cleanly added.
    - chm 10y ago
      Ah, I'm just now learning about the large/small split. Thanks.
- Grue3 10y ago
  Considering Common Lisp is still in use and doesn't need to be re-standardised despite several decades passing since, isn't its standardisation a great success?
  - hga 10y ago
    It's lacking enough things like standardized networking and threading support that, no, many people don't consider it a success. It was also a semi-atrocity in creation in ways that needlessly made it more difficult to implement, but that tale is best told by people more knowledgeable than I, I'd moved onto Scheme by then for the most part.
  - cicero 10y ago
    I think Common Lisp's success is due to the power of Lisp and that Common Lisp is the most modern full-featured version of Lisp. For all we know, if the standardization had been done better, Lisp might be more widely used than it is today.
jabl 10y ago
To some extent I think the R7RS-large effort is a bit misguided. I believe successful "large languages" (as in, comes with a big "standard library") need a large team of professional programmers to implement it all (professional, in this sense as directed by some organization so that they work on what the organization prioritizes rather than on whatever they fancy), and preferably a single implementation so that all the implementation effort can be concentrated on that one implementation. Successful examples of this approach: Java, .NET. Scheme is not anything like the above: Plenty of implementations, mostly by pretty small teams. With ubiquitous internet access, and the rise of open source, I think the better approach for R7RS-large would be to instead standardize a package manager, and then let a thousand flowers bloom. This approach has proved successful, e.g. npm (for node.js), Cargo (Rust), elpa (emacs-lisp), quicklisp (Common LISP). Then again, I'm not a Scheme "insider", so what do I know. YMMV.
- microcolonel 10y ago
  For what it's worth, they did introduce a standard module system. That is the prerequisite to a global standard package repository. I've been following the effort and voted on ratifying R7RS-small. One of the nice things about the large-small split is that it satisfies all parties, while clarifying the specification. It also means that new implementers can start with a R7RS-small implementation, and immediately gain the power of much of the R7RS-large library in a portable form. This benefit is not to be underestimated for the community we're talking about.
  - groovy2shoes 10y ago
    > One of the nice things about the large-small split is that it satisfies all parties, ... Unfortunately not. R7RS-small introduced some incompatibilities with R6RS that caused some R6RS fans (yes, they exist) to dissent. One was samth, as I recall, but I can't remember the names of any of the other outspoken critics of R7RS. If the mailing lists hadn't disappeared, I'd probably be able to find the threads for you. They made some good points. Personally, my gripes with the R7RS-small are pretty minor, and overall I think it's good and I welcome it whole-heartedly. The modules and the records were sorely needed for decades. They were slotted for R5RS, but back then the RnRS was ratified by full consensus rather than majority vote, and some people simply refused to compromise. This is why R5RS took almost 10 years when its predecessors only took a handful of years. (In retrospect, I wish they'd made them an appendix in R5RS, like what they did for macros in R4RS, but it's far too late for that now...).

hvs 10y ago

Any popular language that is going through a standardization process can teach us a lot. As opposed to languages that have "benevolent dictators" (Ruby, Python, etc), languages like Common Lisp, Scheme, C++ have all gone through standardization processes that often leave a lot to be desired. Unfortunately, that lesson usually learned is "don't do it", but I'm hoping that Scheme has righted the ship a bit and R7RS will be able to balance the goals of multiple diverse groups. The last thing we need is another Common Lisp.

chm 10y ago
It's trivial to run R5RS in DrRacket, for example, or other Scheme implementations as well. So it shouldn't really be a problem if R7RS becomes bloated, as you can stay on R5.
- hga 10y ago
  Well, note that this is about R7RS-large; R7RS-small is "a 'small' language, suitable for educators, researchers, and users of embedded languages, focused on R5RS compatibility" (http://trac.sacrideo.us/wg/wiki/R7RSHomePage http://trac.sacrideo.us/wg/wiki/R7RSHomePage see also http://www.scheme-reports.org/ http://www.scheme-reports.org/), its spirit is R5RS cleaned up and with a library feature to allow R7RS-large to be cleanly added.
  - chm 10y ago
    Ah, I'm just now learning about the large/small split. Thanks.
Grue3 10y ago
Considering Common Lisp is still in use and doesn't need to be re-standardised despite several decades passing since, isn't its standardisation a great success?
- hga 10y ago
  It's lacking enough things like standardized networking and threading support that, no, many people don't consider it a success. It was also a semi-atrocity in creation in ways that needlessly made it more difficult to implement, but that tale is best told by people more knowledgeable than I, I'd moved onto Scheme by then for the most part.
- cicero 10y ago
  I think Common Lisp's success is due to the power of Lisp and that Common Lisp is the most modern full-featured version of Lisp. For all we know, if the standardization had been done better, Lisp might be more widely used than it is today.

jabl 10y ago

To some extent I think the R7RS-large effort is a bit misguided. I believe successful "large languages" (as in, comes with a big "standard library") need a large team of professional programmers to implement it all (professional, in this sense as directed by some organization so that they work on what the organization prioritizes rather than on whatever they fancy), and preferably a single implementation so that all the implementation effort can be concentrated on that one implementation. Successful examples of this approach: Java, .NET. Scheme is not anything like the above: Plenty of implementations, mostly by pretty small teams. With ubiquitous internet access, and the rise of open source, I think the better approach for R7RS-large would be to instead standardize a package manager, and then let a thousand flowers bloom. This approach has proved successful, e.g. npm (for node.js), Cargo (Rust), elpa (emacs-lisp), quicklisp (Common LISP). Then again, I'm not a Scheme "insider", so what do I know. YMMV.

microcolonel 10y ago
For what it's worth, they did introduce a standard module system. That is the prerequisite to a global standard package repository. I've been following the effort and voted on ratifying R7RS-small. One of the nice things about the large-small split is that it satisfies all parties, while clarifying the specification. It also means that new implementers can start with a R7RS-small implementation, and immediately gain the power of much of the R7RS-large library in a portable form. This benefit is not to be underestimated for the community we're talking about.
- groovy2shoes 10y ago
  > One of the nice things about the large-small split is that it satisfies all parties, ... Unfortunately not. R7RS-small introduced some incompatibilities with R6RS that caused some R6RS fans (yes, they exist) to dissent. One was samth, as I recall, but I can't remember the names of any of the other outspoken critics of R7RS. If the mailing lists hadn't disappeared, I'd probably be able to find the threads for you. They made some good points. Personally, my gripes with the R7RS-small are pretty minor, and overall I think it's good and I welcome it whole-heartedly. The modules and the records were sorely needed for decades. They were slotted for R5RS, but back then the RnRS was ratified by full consensus rather than majority vote, and some people simply refused to compromise. This is why R5RS took almost 10 years when its predecessors only took a handful of years. (In retrospect, I wish they'd made them an appendix in R5RS, like what they did for macros in R4RS, but it's far too late for that now...).