Ramin Honary<blockquote><p>What I don’t like:</p><ul><li>some stuff breaks “everything is a list” model</li><li>Common Lisp is not minimal, includes overlapping and legacy stuff</li></ul><p>does <a class="hashtag" href="https://fe.disroot.org/tag/scheme" rel="nofollow noopener noreferrer" target="_blank">#scheme</a> address this?</p></blockquote><p><span class="h-card"><a class="u-url mention" href="https://mastodon.social/@rzeta0" rel="nofollow noopener noreferrer" target="_blank">@<span>rzeta0</span></a></span> I would say yes, Scheme sort of addresses those issues.</p><p>Scheme’s biggest advantage is that it is minimal enough that you can understand the whole language specification top-to-bottom, inside and out. But that is also it’s greatest drawback: is that it is too minimal to be practical. So for a long time, every single Scheme implementation has a it’s own large and unique set of libraries for solving practical programming problems that were incompatible with other Scheme implementations, making the Scheme ecosystem very fragmented. The <a href="https://srfi.schemers.org/%20" rel="nofollow noopener noreferrer" target="_blank">Scheme Request for Implementation (SRFI) process</a> is meant to address this fragmentation issue. Fragmentation is still (in my opinion) a pretty big problem, though things are much better than they were 20 years ago.</p><p>The R6RS standard, as I understand it, tried to make Scheme more practical, but it started to become too Common Lisp-like in complexity so it was mostly rejected by the Scheme community — with a few notable exceptions, like the <a href="https://www.scheme.com" rel="nofollow noopener noreferrer" target="_blank">Chez Scheme compiler</a>.</p><p>The next standard, R7RS, split the language into two parts: “R7RS small,” ratified in 2014, which is more like the original minimal core of the Scheme language, but just a few new features, in particular the <code>define-library</code> macro, for modularizing parts of Scheme programs into immutable environment objects. Then they took a collection of “SRFIs” and declared them to be part of the “R7RS large” language standard. The full “large” language specification is not yet fully ratified, even 11 years after the completion of R7RS “small,” but I think the SRFIs they have ratified so far already make the latest Scheme standard a very practical language. The final R7RS standard may end up being larger than Common Lisp, but that is fine with me since it can be almost completely implemented in the R7RS “small” Scheme standard.</p><p>R7RS “small” Scheme, in my opinion, is a powerful but minimal language that exists to implement other languages, but is still useful in it’s own right as a progeny of Lisp. The “R7RS large” language then adds the useful features of larger languages like Python or Common Lisp as a layer on top of the “R7RS small” language.</p><p>The current chair of the R7RS working group is Daphne Preston Kendal, and is often on Mastodon as <span class="h-card"><a class="u-url mention" href="https://chaos.social/@dpk" rel="nofollow noopener noreferrer" target="_blank">@<span>dpk</span></a></span> . She can tell you if I got anything in this post wrong.</p><p><a class="hashtag" href="https://fe.disroot.org/tag/tech" rel="nofollow noopener noreferrer" target="_blank">#tech</a> <a class="hashtag" href="https://fe.disroot.org/tag/software" rel="nofollow noopener noreferrer" target="_blank">#software</a> <a class="hashtag" href="https://fe.disroot.org/tag/schemelang" rel="nofollow noopener noreferrer" target="_blank">#SchemeLang</a> <a class="hashtag" href="https://fe.disroot.org/tag/r7rs" rel="nofollow noopener noreferrer" target="_blank">#R7RS</a> <a class="hashtag" href="https://fe.disroot.org/tag/programminglanguage" rel="nofollow noopener noreferrer" target="_blank">#ProgrammingLanguage</a></p>