R7RS-large kickoff, list membership, and voter registration process
groups.google.com
groups.google.com
"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)#...
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.
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.
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.
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.
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...).
Note that I'm not opposed to the new "80%+ vote in favor" system (I think it's a very good thing), I'm just pointing out the history.
With standardized libraries in R7RS-small the opportunity has existed for sometime for a community-created package manager to come into existence. There are several in existence, mostly targeting particular schemes, but Snow2 is the closest to what you desire.
Why it hasn't caught on is unquestionably, IMHO, because of the limitations upon the R7RS-small language. Library writers often cannot write for standard R7RS and must ship implementation-specific code. For instance, the R7RS opted not to define a standard FFI of any sort.
Even if your library is internally R7RS compliant it is often the case that it may rely on packages which are not, so deploying to the likes of Snow2 is a matter of porting code you didn't write to every scheme that Snow2 supports.
The best reason I have been given for the decision not to define an FFI is because it would force writers of toy schemes to conform their data structures to the standard. And so in an effort to remain a toy language it has restricted itself to being only a toy language.
Use Chicken, Chez, Gambit, Chibi or Racket. Forget about RnRS.
On the other hand, Scheme has been a toolkit to test out ideas of programming languages since its origin. We still keep call/cc not because we use it for daily application development, but rather because it is invaluable to implement new idea of control abstraction portably. With this goal, we don't want to restrict implementation too much (hence the loose definition of "error"), nor want to raise the hurdle of standard conformance by requiring too many libs.
R7RS small/large split reflects this view, and I think it's a good thing. I also think SRFI process is working. If there ever is a common package manager thing, R7RS-large is a step to it. I've been using Scheme at work for last 20 years; let's see what we have in the next 20 years.
The R6RS editors tried to remedy this, but wound up causing a schism in the Scheme community which was pretty damaging. The "50-page-purists" have somehow gotten into their heads that the R5RS is the be-all, end-all of Scheme, and that any additions whatsoever are features piled on top of features. Now, with the R7RS, we've not re-united the Scheme community, we've fractured it yet again. There are now three factions (in no particular order): (1) those who think the R7RS sucks because of gratuitous incompatibilities with R6RS; (2) those who think the R7RS sucks because it's got more features than the R5RS; (3) those who like the R7RS.
Personally, I find that a module system and user-defined records are extremely welcome, and a long-time-coming, really, but I fear that the R7RS-small on its own is still too small for something like Snow2 to really take off in an implementation-independent way.
In short, I agree with you. But, it's complicated.
Again, maybe that's way off, but I find the interface horrible and dated and only ancient projects seem to use it...
Three major drawbacks compared to mailing lists: it's on-line, it's proprietary, it sucks for searching and filtering (seriously, the few tools it gives you are a fraction of what you get in any e-mail client).
Do you mean like Golang? (https://golang.org/help/)
I also like J [2], and the Google Group gets less traffic than the individual direct email lists.
As long as I can communicate, and stay current, I really don't care if the site looks good, as long as it is easy to navigate with old styling.
[1] http://picolisp.com/wiki/?home [2] jsoftware.com
I only care about quality, not quantity or popularity when selecting my tools for a task. There are people doing real work with both J and PicoLisp. Look at KDB+/Q. It is a highly effective time series database/language that is used by some of the largest companies, but could be called niche, yet the kx.com site is modern, but look at kxparc.com which is Arthur Whitney's site. He created A+, K and Q, and inspired J, yet the site is basically plain text and minimal, the beginnings of a desktop and server OS in K, KOS.
BTW, J has Jd, a time series dbase with J as the built-in language of you're interested in that sort of stuff.
I am more a "function over form" kind of guy, although I understand the importance of appearance and human interface designs.