It'd be neat if someone familiar with Scheme standardization laid out some of the big disagreements in R7RS-large, or else most of this thread will just be a Scheme vs. Every Other Language discussion.
I've been trying to get up to speed myself. It seems like the best way is simply reading the mailing list and checking out the codeberg issues. This issue [1] was given as an example of a non-technical problem that's easy to get distracted by when most of the core technical work should be straightforward. It's referenced in this candidacy statement [2] for John's chair position which is a good read to understand what's happening. It's essentially the classic language debate of breaking compatibility with past version versus evolving the language, and seems pretty complicated. I'm sure there are other problems. I'm still reading.
The second link provided here has a little overview of Daphne's thoughts on why things are dragging on:
> The establishment of the central issue tracker is, I reckon, more to
blame for the current disputes. The old model of periodic ballots
provided the community with focus; the issue tracker has the problem
that, since all currently outstanding problems are listed in one
place, any such problem can become a focus of attention at any time,
and then arguments about the details of that problem erupt. John has
observed in #scheme that the more into detail we get, the more we seem
to argue, which seems accurate. It has also, in practice, become a
place where issues related to the Foundations only are discussed, and
work on the Batteries has mostly stalled. Mea culpa!
r6rs was hugely controversial for many reasons. r7rs-small went back to the r5rs roots, whereas many of us (yes, me included) thought building on r6rs would be the better choice.
Much of the process that was started in r6rs led to racket. Kent Dybvig was the head of the standards body and the racket folks were also active in the mailing lists. I think a big part of the disagreement was about correctness. r6rs guarantees some things about a running program that is difficult to do for many small hobby projects. There was also a discussion started about things like immutable data (pairs and strings, mostly) which got people all hot and bothered.
The problem with r7rs-large is that it will have to solve many of the problems solved by r6rs (low level macro system, how to handle unicode etc...) which means redoing the r6rs work.
The Scheme community has long held tension between people who want to use Scheme as a teaching language, versus those who want to use it for writing real-world programs.
The former want the language to stay as minimal as possible with a tiny standard library so that there are fewer concepts and options for students to stumble over. The latter want a full-featured language (but still minimal, it is Scheme after all) with a large standard library of useful types and functions so they can get stuff done.
These two perspectives are both reasonable but fairly incompatible.
For most of its history, Scheme leaned towards education. Around the type of the sixth edition (RSR6), pulled somewhat the other way and the language and library spec got much bigger. This alienated a lot of folks who wanted to stay a small teaching language.
For RSR7, they tried to resolve that by simply splitting the language in two: a small one and a large one. Then each subcommunity can have what they want.
Around the same time, the language PLTScheme renamed itself to Racket to clarify that they aren't trying to be beholden to the overall direction of the Scheme community. Racket is also a "large Scheme" in that it's a Scheme-derived language that tries really hard to be batteries included for all sorts of uses. It also can be "subset" into smaller languages for use in teaching.
My impression (from far on the outside) is that Racket has taken up a lot of the oxygen, which may partially explain why RSR7-large never managed to reach consensus and ship.
> My impression (from far on the outside) is that Racket has taken up a lot of the oxygen
For real world applications rather than education Racket and Clojure as well, in fact Clojure has taken up a lot of the oxygen across a variety of niche FP language eco systems. The Clojure toolchain and library support (much of it through the JVM and Java ecosystem) is excellent and far ahead of Racket for most of the same applications. But Racket starts faster and has a much smaller memory footprint. Depending on your workload and compatibility demands either the one or the other will be a clear favorite with Clojure coming out ahead.
But all of these and scheme (which I think is mostly propped up by virtue of being used a lot in education, I've yet to come across scheme in the wild) are very much niche languages. Clojure really does have an advantage of standing on the shoulders of Java and the JVM, without that I don't think it would have gotten as large as it did.
The aggression in your response is entirely disproportionate to the comment you're replying to. I don't know who peed in your Cheerios, but it wasn't jacquesm.
We're talking about a minimal dynamically-typed Lisp language and speculating about its challenges around adoption and consensus. Given that Lisps are already a niche language, it's completely germane to bring up another minimal dynamically-typed Lisp that has almost certainly captured some of the overall small potential userbase.
Well, that may be your impression. But I know of two cases where scheme was being considered for commercial work and in both of those the decision was made to go for Clojure instead. It was relative to Racket as a replacement for more real world applications of Scheme that I mentioned this.
It's the Revised Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme, or (Revised)^7 Report on the Algorithmic Language Scheme, or R7RS.
(Because, of course, Scheme folks couldn't resist the urge to use a little recursion in the name of the spec instead of defining it as an iterated series of version numbers.)
Thanks for the summary. Unless I am missing something, this seems like a pointless argument that the scheme community has. Why not just create a library separate from the standard and call it a day?
Thanks for giving some context on the matter. If the base language is not capable to provide a way to implement those, then that makes sense. I do like the idea of having the base being small but still capable to allow for these features to be implemented in a library. From the link you gave, it does seem that these would require more support than what is available in a smaller language.
I don't have much more context than you, but one bit I did catch is that this resignation is for "R7RS-large" and not "R7RS-small" (which might even be complete already).
Traditionally, Scheme is as minimalist as possible by design. Therefore, the very idea of "R7RS-large" is likely controversial to some parties involved.
Apparently it has been an on-going argument for years on just what to include in R7RS-large, as we can see a Reddit thread from 2 years ago asking when it will be ready[0] and John Cowan (the person who is resigning from the committee) saying parts one and two are done and part three should "follow quiuckly thereafter".
> That depends entirely on how much time people can devote to it. The first two parts, Red and Tangerine, are already in place; Orange needs a few things pulled together before it can be voted on, and Amber should follow quickly thereafter.
I'm guessing getting that last 90+% of agreement stretched ever further and further on and as John said in the resignation letter, it was surely exhausting.
Spot on, that's why scheme is and probably always will be very much a niche language. They're not even trying. I wished we could collapse the Cambrian explosion of computer programming languages back into a small subset of what it is today to get fewer but healthier eco-systems. The amount of fragmentation is absolutely insane, and leads to a ton of duplicated effort and wasted resources. There are 100's of computer programming languages in active use and beyond say the top 100 or so there isn't much that isn't already covered multiple times.
But with the widespread connectivity that we have it is very easy to launch a new language and to gain some small level of adoption. Programming languages are like kids: you can launch them in a night but it takes a lifetime of dedication and support to make them successful and given how hard it is to distinguish a small effort going nowhere from a future winner all this does is saddle up outsiders with the cost of maintenance or ultimately a rewrite in some other, hopefully wider supported language.
It would be great if people would just label their languages clearly as 'experimental, not meant for production' and 'long term supported' up front. Some languages, notably, 'Haskell' are successful in spite of actively holding back large scale adoption. This is a much healthier approach. It shows that the language really has merit.
If you really want to undo the Cambrian explosion, you will get Fortran and Lisp. A better SQL, Prolog, and something like Haskell might also be useful/necessary.
I think programming language standards committees are not an unlikely venue for hot conflict, quite the opposite if you talk just about conflict without the word "hot". I don't have the background on this one though.
Do you have any experience reaching to similar organizations? for example reporting compiler or linker bugs or trying to get support for new features or platform that are not well documented? If you don't and think it sounds fun go ahead and have fun if you can do that work without getting dragged into hot conflict.
Lisp is 65 years old and its future will be longer than its past! Another way to look at a fast-moving industry is that it's all hype and flutter with the occasional solid achievement.
Yeah, I think there's an ambiguous connotation sometimes, such as in "academic politics is so fierce, becuase the stakes are so small" that it might just be people being petty about, say, small-pond status, because they have nothing else.
In this case, however, it might be more that there's an innate value that a small number of people recognize as important, so they care about it in a way that seems outsized, to people who aren't aware of that importance.
It's the Revised Revised Revised Revised Revised Revised Revised Report on the algorithmic programming language Scheme. That's 7 "Revised"s, hence R7RS. Basically the RxRSes are full specifications of what you need in a Scheme implementation to conform to the Xth iteration of the language.
So weird seeing CL code without a bunch of (declare (type (integer 0) n))'s everywhere. That's the only thing which keeps me with CL instead of Scheme (I'm rather fond of syntax-rules, case-lambda, case sensitivity, and being able to do things like...
(define range+ (make-range-merger +))
(define (double-range range)
(range+ range range))
Revised report version 7. The current scheme standardization. It proceeded R6RS which many felt was too large, and added too many things to the scheme standard (it’s only 90 pages long). R7RS was the compromise
Exactly. R7RS-small was meant to be a minimal core language, in the spirit of RnRS for n <= 5, whereas R7RS-large was meant to be a fairly complete set of standard libraries.
What's the overall Scheme community look like these days? How much are new libraries targeting the specifications (like R6RS) vs. just targeting a specific implementation like Racket, Guile or Chicken Scheme?
What forces are keeping the various implementations aligned and moving in the same direction? What is driving them apart? What does the future look like?
I'm just watching this as an observer, but I suspect a lot of it is:
People who want to write real-world Scheme code have a strong incentive for a single definition of the language so that their code will reliably run on multiple implementations. They want one language and are probably willing to deal with some breakage in places where implementations are alreaday incompatible in order to get there.
People who maintain Scheme implementations want backwards compatibility so that they aren't forced to rewrite a bunch of already working implementation code or try to support multiple different languages at the same time. They don't want to make breaking changes to their implementations and break all of their users in order to converge towards some other implementations' behavior they may not care about.
Teachers want a language that is maximally elegant and minimal. They are perfectly happy to make tweaks to the language to make it incrementally cleaner even if it breaks tons of existing code because most of their code is short-lived anyway.
Reconciling these very different incentives does not sound fun.
I am usually only targeting guile, mostly because of guix. Guile or chicken seems to be the most popular schemes, but Chez is a compelling choice when there are no external dependencies.
Hi John! I have always made the claim that racket (minus the #lang bit) is the natural continuation of r6rs. Delimited continuations, immutable pairs, continuation marks and such. They also chose, in my opinion, some more sane paths with regards to the dynamic environment and laziness.
If one could make a wish list it would be the suggestions in Marc's proposal in the chez issue tracker, immutable pairs, immutable strings, and RRB trees in the standard library. Like an opinionated love child racket and Clojure :)
Even though I am more.of an r6rs guy I have always applauded r7rs large. At the same time I am glad you put your own health first. That is always the most important. Apart from the r7rs process, your contributions to all SRFIs I have been following has been amazing.
It's currently used as a back-end for the Idris language. (Which is primarily a research language, admittedly.) It's a fairly popular target for languages to compile to, for similar reasons that C is -- small, well-defined, minimal, many implementations, runs just about everywhere. Very nice compilation target for functional languages in particular, as call/cc can, with reasonable efficiency, implement just about any kind of control flow/evaluation/threading model that you can think of.
C is neither minimal nor well-defined, as has been discussed extensively. Random blog post illustrating only some of the issues is here [1]. Just google “undefined behavior c” for a lot more. There are also a bunch of famous rants by Linus Torvalds on his topic.
can we all agree that the undefined behavior is pretty well identified and documented? Plus, if you understand the entire language and then limit your imagination, C can be quite simple!
> Idris is primarily a research project, led by Edwin Brady at the University of St Andrews, and has benefited from SICSA (https://www.sicsa.ac.uk) and EPSRC (https://www.epsrc.ac.uk/) funding. This does influence some design choices and implementation priorities, and means that some things are not as polished as we’d like. Nevertheless, we are still trying to make it as widely usable as we can!
At this point, the creator has described it as "Pac-Man complete", able and easy to implement a game like Pac Man. (Or itself - it compiles to Scheme but is written in itself.)
Dependent types are still rather new; I believe Idris and its libraries are one of the largest, if not the largest, body of general-purpose software that uses them. (F* maybe?) How to use dependent types properly in a standard library seems be an ongoing development.
The Pac-Man Complete bit is tongue-in-cheek. It's an observation that TC is rarely (if ever) actually needed in practice.
(This might sound strange to people unfamiliar with dependently typed langs, but infinite streams etc., servers that "loop forever" doing request-repsonse can still be modeled without TC.)
It's intended to be a practical research language. Its niche is as a dependently typed language that is useful for writing real programs. But it also needs to be a toolkit for research into dependently typed programming, since most of the devs have to publish.
Both of the links you share contradict your statement. ARC isn't scheme, and the hacker news link you posted as a source doesn't mention scheme either.
* I really enjoy using numeric towers and it is upsetting to me every time I go to another language where I can't just work with rationals as a default.
* Having statistics functions, a GUI library, and a plot library all part of the standard distribution is wonderful. Dependencies are kept to a minimum, which I appreciate. Everything feels coherent and not over-engineered.
* Poking around in the large standard library was straight forward and not difficult. I added candlesticks [1] to the plot library without understanding much of the plot library's design or implementation details. I think this would have been much more involved in many other languages.
Where I perceive Java as nicer than Racket:
* I wish Racket had real threads like Java. Having futures and places for actual concurrency / parallelism is not as nice.
* I wish Racket had the rich data structures built in as Java has. You need to reach for an external library for a sorted data structure; this is not ideal.
* Java's performance is great and its future is promising. Java already has some great GCs including low pause time GCs, Project Valhalla will add value objects to Java, and Project Loom will enhance the concurrency functionality offered in Java.
I don't have much JavaFX experience, but my perception is that it would be fine and just as "cumbersome" as Racket's GUI and plot libraries.
Racket is very used in the PLT community (programming language theory) for prototyping programming languages. Lots of cool stuff in this area.
For example, the MIR formality [0] project of the Rust programming language to formalize MIR (their intermediate language) was first prototyped in Racket [1], then rewritten in Rust. [1]'s readme give a rationale:
> For the time being, the model is implemented in PLT Redex. PLT Redex was chosen because it is ridiculously accessible and fun to use. It lets you write down type system rules and operational semantics and then execute them, using a notation that is very similar to what is commonly used in published papers. You can also write collections of unit tests and fuzz your model by generating test programs automatically.
> The hope is that PLT Redex will prove to be a sufficiently accessible tool that many Rust contributors will be able to understand, play with, and extend the model.
> One downside of PLT Redex is that it doesn't scale naturally to performing proofs. We may choose to port the model to another system at some point, or maintain multiple variants.
Guix is niche, but it's very much 'real software'. It does useful things well, and it solves some problems that very few competitors adequately do. It's used for reproducible scientific computing on some HPC clusters, which is a pretty cool niche if you ask me.
The Guix package collection is also sizeable and growing exponentially-- within a few years, it'll probably outgrow most Linux distros in terms of size.
I had to use Nix in a project of mine and was surprised at how clunky it felt compared to guix. Writing packages meant string concatenations and juggling outputs to the command line.
Same here. I used NixOS as my desktop operating system for a few months I think. It did not go great. After hopping a to a few other distros, now I've been using Guix as my OS for a few years.
For "precisely" read "correctly". Unless the implementation language is exposed to users of the implemented language, it doesn't matter what the implementation language is. gfortran is written in C and C++, but that does not mean Fortran programs are written in C or C++.
Okay, I think what I said was clear enough, but if we're splitting hairs, I'll say: that's a bad comparison because gfortran is compiled to machine code. When you run a gfortran program, you're not executing anything that was written in C.
When you run e.g. Python, the runtime written in C is indeed being executed. If nothing else in the world was written in C except the Python runtime, IMO it would still be fair to say that C is widely used. A security flaw in C compiler could potentially cause a vulnerability in any Python program.
The question was "is Scheme used for anything in production?" and it is correct to say "yes it is used for HN" even if HN is not directly written in Scheme.
I chose Racket for a project that involved lots of AST manipulation. Those ASTs were already in s-expression format, so Scheme seemed a natural fit.
The lack of static types was annoying; Typed Racket helped, but was so slow I only enabled it during unit tests (more precisely: Typed Racket functions can be faster than those written in normal Racket, but calling them from normal Racket functions will be slow as it performs run-time checks)
Around 20 years ago I worked on commercial email filtering/archiving system implemented in MzScheme (now PLT) - it was relatively small code base, but very powerful.
How do you handle Gerbil's incomplete docs? I'll admit, when I was looking at them I had no clue how Schemes worked, but I found the lack of documentation to be a very difficult barrier.
Gitter has been a great resource. Vyzo is very helpful in answering questions. The docs could use some work. But the code is fairly trivial to follow on most things.
The issue is that lots of languages don't make complex numbers part of what Lispers call the numeric tower, fully integrated into numeric operations, even if there is a complex library. Here's Guy Steele's 3-part smoke test for early Common Lisp implementations:
1. At the REPL, if you type `T` (true), and you get back `T`, the test passes.
2. Define factorial. Then type `(/ (factorial 100) (factorial 99))`. If you get back 100, the test passes.
3. Type `(atanh -2)`. If you get a complex number, the test passes. If you get the correct complex number [namely -0.5493061443340549+1.5707963267948966i] extra credit. Far too many non-Lisp languages return NaN or throw an exception.
Okay, I was just wondering if there's something non-obvious here. I guess OP is just woefully misguided about languages other than scheme or "these languages can't handle it" means something more like "I don't know how to use those languages".
Decent complex types and library calls to do exponentiation, etc, don't always come for free in any given language environment. It's nice that it "just works" in many scheme environments (but this is not the only language runtime where this is true and it's not something that you can't work around).
yeah it looks like everybody's focused on the mechanics of the computation and not appreciating the math i.e. why the two expressions compute to the same value.
I think the biggest issue with any lisp is that it's just too damn powerful of a language. This makes it super easy for developers to create their own little ecosystem of macros and functions that nobody else can understand. This can be absolutely disastrous for large teams and companies looking to hire.
Languages that force you to be more verbose and don't let you build your own ultra-powerful abstractions seem to work better for large teams where you can force everyone to adopt a standard style. This makes onboarding much easier too.
I dunno, I got a (Common) Lisp job, and I don't think I've ever had a problem where I didn't understand the semantics of a macro; people aren't just making a ton of them all the time for no reason, and the ones that are popular are from popular libraries (e.g. alexandria and iterate) and have clear semantics.
I think the same problem applies perfectly well to developers who "create their own little ecosystem of classes and functions nobody else can understand" -- I don't think [0] would be made any harder to understand by having macros involved.
People say this, but it hasn't been my experience in practice—the worst, most complex codebases I've seen have been in Python and Java.
But I guess they look simple and uniform at a superficial, syntactic level. If you can't follow that it's your fault, if you can't follow Lisp code it's Lisp's fault...
For now, yes. The upcoming 1.10 release (which is now in beta) will switch to a pure Julia parser as the default (with the old Scheme parser available as an option).
Not because of any fault with Scheme per se (afaik), just that contributors to Julia are more likely to know Julia than Scheme, so it makes sense from a maintanence point of view.
Like all lisps it is niche. I don’t use scheme but have used Common Lisp and clojure for a few years. Racket has a thriving community as far as I can tell. You just don’t see lisp much in the wild but it’s there.
My totally uneducated and uninhibitedly snarky guess is that people who use any Lisp family language (except maybe Clojure) don't go around talking much about that fact, or thumping their chests about it, unlike (some) Ruby, Python or JS users. They probably just quietly go about using it and having fun, and talk about it when they meet each other.
I hate that the world sometimes requires a human sacrifice in order for change to happen. I can empathize with people that say this is a stupid way to fix a problem, but unfortunately the world is full of stupid things that actually work.
On one project, we had a horrible integration test system that required a human to read and interpret the output. The guy who wrote it made his own DSL. As we struggled with it, he noped out and left the project. The next guy had partly the right idea. He figured out how to translate the whole thing into Python with a couple of macros. So at least you could step through it. Then he noped out. Since I do a lot of CI/CD work and my primary goal on the project had already been fulfilled, I took over. What a mess. I made it better but I still couldn't nail down pass/fail statuses reliably. Pointless system.
I kept harping on how we needed to throw out the whole thing. It was a false sense of safety at best. When I left to work on something closer to my life goals, at the very last big meeting one of my people I'd been mentoring said, "The last 3 people to leave this team worked on this one project. Maybe we should get rid of it." and everyone started nodding. Son of a bitch.
Now, I wouldn't have stayed anyway, but someone else might have. I've seen other situations like this play out, and while there's always gonna be someone who 'takes their ball and goes home', often enough it's someone reasonably determining that they cannot or will not be responsible for the chaos represented by Option A over Option B. This will burn down, fall over, and sink into the swamp.
That's what I mean. For this to be some place people like working, someone has to leave over the status quo. Which means they don't get to benefit from any of the work done so far or subsequently.
There used to be a website a long time ago, but for now your link is it, unfortunately.
R7RS is the Revised⁷ Report on the Algorithmic Language Scheme, the latest common-ground description of the language.
Revisions up to and including R5RS were fairly minimalistic (even if not all of the features new to R5RS are uncontroversial) and specified essentially no library facilities, which were usually either completely implementation-specific or released as RFC-style documents called SRFIs (Scheme requests for implementation). As a result, toy, teaching, or research implementations of Scheme were fairly easy to make, but moving programs between implementations was a bit of a crapshoot.
The reaction to that was R6RS, which is—if not the length of the Common Lisp spec—similar in scope, with utility and OS interface libraries, an extensive macro system, a freshly designed module system, and a lot of other stuff. When SRFIs for the new functionality existed, R6RS certainly took inspiration from them, but its redesigns were neither fully compatible nor taken through the public SRFI process (the standard was still subject to public discussion, but in a different venue with different procedures). And people wanting a minimal standard to implement on their own (a not insubstantial part of Scheme users) were told that R6RS wasn’t for them and pointed back to R5RS.
Long story short, the few commercial Scheme vendors (first of all Chez Scheme, prior to the Cisco acquisition and open-source release) largely adopted R6RS; the rest of the implementor community largely ignored it or cherry-picked some parts—and that means not only the myriad hobby implementations, but also the medium-scale ones like Chicken, Gambit, or Gauche. I think even Guile (whose stance on minimalism mirrors that of most other GNU software) requires some wrangling to get it close to R6RS.
R7RS was intended to close that divide: there’s R7RS-small, which is an R5RS-style lean spec, and R7RS-large, which was intended to be a R6RS-style real-world language, but composed with more respect to existing practice and SRFIs and with more implementor buy-in. It was to be released in several issues organized by topic (data structures, I/O, etc.). John Cowan managed to get a couple of these out the door over the last decade, but the efforts seem to have stalled. AFAIK Chez, the gold standard of real-world implementations how that PLT Scheme has reinvented itself as Racket and gone its own way, has also indicated no interest in even looking at R7RS-large however nice it turns out, because they have customers now and that takes priority over ecosystem health.
Racket is not an extension of Chez; Chez is an implementation language for Racket (it replaces most of the C code in earlier versions). See my comment above about implementation languages.
The main benefit of basing Racket on Chez instead of C was maintainability. A bit of performance and a few fairly unimportant features (like single floats) were lost.
Eh. Giant headaches is overstating it, I think, if we're talking Lisp post 2005 or 2010: Common Lisp implementations are largely compatible; Racket only has one implementation (and no spec); in Scheme you'll have to spend a bit of time porting between the three or four big implementations that can actually run your stuff, big whoop. (On this forum I probably have to mention Arc, but I don't believe it ever grew beyond a personal project.) I'd say that the main obstacle to adoption was rather the (apparent) absence of shinies (and boy were there a lot of competing shinies at the time).
Even if this were correct, though, my experience is that I find very little enjoyment in things that are targeted at what in your terms is success. For example, Go feels dreadfully unpleasant even though I can't deny the good—occasionally downright brilliant—engineering that went into it, kind of like a mass-produced concrete residential building. Let's be honest, I'm in this largely for the hackery, a little bit for the feeling of having solved somebody's problem, and not in the slightest for the social acceptance. You might not agree here (or you might!), but I hope that, if one day nobody does, I still have the self-awareness to step away from the computer and go do something else.
> For example, Go feels dreadfully unpleasant even though I can't deny the good
For me Go feels like Pascal cut off C's face and is wearing it Hannibal Lector style.
That said, it's an absolutely fabulous language, standard library included, for implementing a worldwide ads serving network. Gotta give them that. For other problems that are more or less technically similar it's also great.
That’s not quite so true. The Common Lisp standard actually works pretty well for having many conforming implementations. For example SBCL, which it’s fair to call a nontrivial program, is portable across itself, CMUCL, Clozure CL, CLISP, ABCL, and ECL.
On the other hand, a theorem prover written by John McCarthy in 1958 was trivially adaptable to both Common Lisp and Scheme. Not too many languages get to make that claim.
Thanks, that is helpful background. I can see how it would be difficult find agreement between groups who want compatibility with R6RS, and those who want compatibility with SRFIs.
The 7th version of the Scheme standard/specification, basically. There's a "small" and "large" version of it, for different use cases/preferences (there's a bit of drama behind this: R6RS introduces a lot of "large" features that many implementers felt were too "bloated", which was eventually resolved by splitting the standard in small/large variants).
I got involved with scheme back in the days of R{5,6}RS (as a user, not in the standards process). Even then it was an argument for the BDFL model over design by committee.
Committee consensus took us up through R5RS. There were about 30 members of the committee, though obviously some were more active than others. The problem with that was that we got no change except at the margins. Implementations were extended in random incompatible ways.
Then we had consensus of a small committee (5 members, later 4) for R6RS, followed by a community ratification vote. A lot of people thought the resulting standard was over-engineered, and I am quite sure that many people didn't understand all of it (I didn't for sure, especially macros and records.) Some implementers adopted it, others declared they never would.
For R7RS-small and the early stages of R7RS-large, we had the open SRFI process (anyone can propose, the community helps refine, the author decides when to freeze the result).
Now we have a (de facto) Sitzfleisch process: however stays in their seat and is still arguing the longest, wins. I eventually ran out of energy for this one.
Note that in all cases the text controls the meaning, not the author(s), and when the standard and an implementation collide, it is the implementation that is wrong. This is very nearly a sacred principle, as in C/C++ and various other multiple-implementation languages.
I wonder if the optimum is a benevolent dictator controlling the language and committee controlling the associated library. The community is then a sort of third ring of library evolution.
Inconsistency is more expensive the closer to the language definition it arises as the blast radius is wider.
Compromises and redundancy are more valuable in the library layer.
Lisp blurs the lines somewhat but it's usually possible to subdivide a system into a core and stuff built on that core.
As someone who works on a combined language/core library team, it's really nice to have them both under the same roof. We can provide a much better overall user experience when we can design features that involve the language and core libraries working in concert with each other.
For example, we recently added tuples as a language feature to Dart, and also added a function in the async library that lets you await a tuple of futures in parallel and returns a future of the tuple of the resulting values.
When we added extension methods to the language, we also rolled out some extension methods in the core library.
What if they (whoever it is, who could or should do this) worked on a proposal, that specifies, how language features should be added to the language? I mean, there are things like continuations and macros. Those need to be really solid. But based on them, could one not make everything else an optional addition, implemented on top of them, instead of in a dialect's core? So that Schemes could all go for R7RS small (except those that object to things in it) and then basically have a "folder" in their sources of things that are additionally necessary to have R7RS large things? Those things being implemented in the way that the standard proposes? Then we could get to a R7RS large step by step, feature by feature.
I guess this depends on whether things in R7RS large are at their core incompatible with how R7RS small works. Probably it also depends on those dialects implementing the standards correctly for the primitives, that the extension mechanism is supposed to be based on.
I also don't know enough to tell what attempts have already been made to resolve things, so perhaps someone already had this idea and it does not work.
Alas, no. There are quite a few other things that are needed in what is now being called the Foundations in order for adding features to be done through libraries. Scheme, like other Lisps, is almost all "library" and very little "language", once you get past variables, constants, and function/macro calls. The only "language" feature added so far (in R7RS-small) is that previously a vector constant had to be quoted, whereas now it is self-evaluating: you used to have to say (vector-ref '#(a b c) 0), whereas now you can leave out the quote mark.
If you want a large language, isn't it a better idea to build it on top of something the makes better guarantees for the user? I prefer my program to not continue executing after reaching an erroneous state.
Of course not, but knowing that the program should never continue executing in an erroneous state is for me a pretty nice-to-have. Scheme enforces correctness and safety in many places and I think that one in particular is important enough to warrant being opt-out rather than opt-in.
i never actually understood how r7rs is supposed to work in practice, because when i learn a scheme i’ve always just learned how to use implementation-specific functionality
Additional background would be nice. I clicked the link out of curiosity to see what it meant for a piece of furniture to resign from something. After clicking the link, I was no better informed.
I almost posted this an hour ago, and feel more comfy now that it’s an hour later:
I’m sad how quickly this rocketed to top 3 on front page and how little content there is, it’s just someone resigning from a project virtually none of us know about. The “My resignation letter” was titillating enough to skyrocket upvotes and engagement
You may be surprised! For context, R7RS is the latest standard for Scheme. Actually it's two standards: a 'small' one for the core language (similar to R5RS; this was finished a decade ago), whilst this involves the 'large' standard, which is trying to agree on a "standard library".
Some reasons people may have upvoted this, or otherwise be interested in Scheme:
- R7RS has been dragging on for so long, it may be nice to see some/any sort of status update
- Scheme has so many diverse implementations (Racket, Guile, Gambit, Chicken, Chez, Stalin, etc.) that it's really important to have some common standards.
- Scheme was a major influence on Javascript (along with Self)
- Scheme pioneered many features that are now taken for granted, e.g. first-class functions (it's a "1-lisp"), lexical scope, tail-call elimination, continuation-passing style, call/cc, etc.
- Scheme is commonly used as a scripting language by applications written in other languages (similar to Lua). Indeed, Guile is the "official" extension language of the GNU project (e.g. see Guix, Shepherd, etc.).
- Scheme was/is taught at many schools and university courses
- Well-known textbooks like SICP use Scheme; and indeed guide the reader through writing their own implementation!
- Scheme is used for programming language research (e.g. "towers of interpreters", (delimited) continuations, miniKanren, etc.). Indeed Racket used to be called PLT Scheme (PLT = Programming Language Theory)
I knew about it! I have been following JCowan's work on this and other similar areas (like SRFI https://srfi.schemers.org/ which may be a more tractable approach to growing Scheme). He's an amazing force for good!
I upvoted because I'm involved in a growing OSS project that's tangling with similar questions of scope and governance. Simultaneously being responsible for everything from software deployment and PR reviews to project scoping and interpersonal conflict de-escalation is absolutely exhausting. I'm fantasizing/extrapolating that many of the people writing "so sorry to see you go" messages were the ones being quarrelsome and refusing compromise, and now they're getting the defect-defect outcome.
Not the case. Anyway, it's not about being quarrelsome, it's about having a different point of view. As for compromise, it's hard to compromise between strictness vs. laxness, for example.
Child A: I want the whole pie!
Child B: How about we split it 50/50?
Adult C: You two need to compromise. A gets 75%, B gets 25%.
(I am not implying that any particular persons are A, B, and C here.)