What I don’t like:

• some stuff breaks “everything is a list” model
• Common Lisp is not minimal, includes overlapping and legacy stuff

does #scheme address this?

@rzeta0 I would say yes, Scheme sort of addresses those issues.

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 Scheme Request for Implementation (SRFI) process 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.

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 Chez Scheme compiler.

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 define-library 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.

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.

The current chair of the R7RS working group is Daphne Preston Kendal, and is often on Mastodon as @dpk . She can tell you if I got anything in this post wrong.

@xameer the “R7RS small” Scheme standard has a full numerical tower built-in, including unbounded integers.

(- (+ (expt 10 100) 1) (expt 10 100))

gives you precisely the correct answer without any floating-point operations. Although macros for symbolic computation with optimization that would avoid computation of (expr 10 100) is “an exercise left to the reader.” Haskell might do the optimal computation though thanks to it’s lazy evaluation.

Are you a Lisper? If yes, What made #lisp special in your view?

@lxsameer a few things:

• absolute minimum amount of syntax, makes it very easy to understand how the computer sees each part of the program, makes it easy to implement your own parser if you want to.
• the ability to define your own evaluator for Lisp syntax, also made considerably easier than other languages due to the minimal syntax. This also makes it easy to develop your own tooling, or to modify existing tooling for the language, which brings me to the next point…
• macro programming: the ability to hack the Lisp compiler itself so that it can run your own evaluator. This allows you to introduce language features when and where you need them, like linting, type checking, literate programming, alternative evaluation strategies (e.g. lazy evaluation, or concurrent evaluation), etc.
• functional programming: it is based on the mathematics of lambda calculus, which is a very elegant way of defining algorithms and computation. It is also a computer for the “untyped lambda calculus“ which can implement any other typed lambda calculus as a system of macros.
• homoiconicity, again a feature of the minimal syntax, allows you to express programs as data, and data as programs. This is very useful for serialization and transport across multiple computers.
• REPL-based development, which is a feature many languages have nowadays (although Lisp invented this feature), allows for rapid prototyping and easier debugging.
• stability: Lisp languages like Common Lisp and Scheme have changed very little throughout the decades as there is no need to change them. Macro programming makes it so that you don’t need too add new language features all the time, language features become extensions you can import into your project.

me, scoffing: dude there’s like a million of those. what, does yours compile on a pregnancy test?

@garbados I can’t find it now, but someone apparently wrote a #SchemeLang that compiles to Ethereum smart contracts. Being that it runs on the cryptocurrency blockchain, they called it “Pyramid Scheme.” It may have been a joke, but I think someone actually did that.

I have challenged myself to try to get my large Scheme code base to compile on any #Scheme I can find that claims to conform to the #R7RS standard. So far I can get a significant portion of it to compile on #Guile (reference), Gambit, MIT Scheme, #Gauche, and Chibi. I hope I can get it to build on Chez with the #R7RS compatability layer built-in to the Snow Fort package manager.

what are the differences between resurrected GuileEmacs that was also announced in EmacsConf2024 and Gypsum? At first glance seems like both projects have the same goal.

@ram535 thanks for asking! The goal for both projects are similar, but they are achieved in slightly different ways.

Gypsum is a clone written in Scheme, meaning it is software the behaves exactly like Emacs, but it is written from scratch in a new code base. In this case, it is also being written in a completely different programming language, Scheme instead of C. The larger goal is to have an Emacs that is backward compatible with GNU Emacs but is written in Scheme that runs on any R7RS standard compliant Scheme implementation. There is no C code in this project at all, it is purely Scheme. I would like to also target other compilers such as MIT Scheme, Gambit, Stklos, and possibly Chicken and Larceny as well, though this will be pretty difficult and rely on a lot of cond-expand code. The larger goal is to have an Emacs app platform that encourages the use of the Scheme language for creating applications and text editing work flows, regardless of the underlying compiler.

@lispwitch ‘s “GuileEmacs” is not a clone, but a fork of both GNU Emacs and GNU Guile, meaning it modifies the existing GNU Emacs code base and some of the Guile source base, replacing some of the C source code in GNU Emacs with other C source code from Guile. Then, the Emacs Lisp interpreter written in C is replaced with an Emacs Lisp interpreter written in Guile Scheme. This allows Emacs Lisp to be JIT compiled using Guile’s JIT compiler, and also make use of all of the Guile software ecosystem to extend Emacs. This is incredibly useful, because there is quite a lot of Guile software, including things like web servers and game engines, and soon it could all be available for use by Emacs programmers. It will probably also be production ready much sooner than my Gypsum project because it only needs to implement the core of Emacs Lisp to work. However, it relies on language features specific to Guile to achieve this, so it is not fully R7RS standards compliant, and will not work on other Scheme implementations.

The parent of this post is my talk at EmacsConf2024 on PeerTube. If you reply to this post here (not the parent), I can see comments on the video and reply to them.

“Question for lispers with experience: If you should start to learn a LISP style language today, which one do you pick up? Why?”

@syntaxerror The R7RS “Small” Scheme standard is roughly 80 pages, so you can learn about all of the language features very quickly. I love it because of it’s minimalism, it is my preferred language.

My take on it is that the “Small” Scheme standard is perfectly designed to construct larger programming languages with more features. One such language is R7RS “Large” Scheme, but you could theoretically use it to implement Common Lisp, Python, JavaScript, or any other language.

The R7RS “Large” standard is still being discussed (10 years after “small” was ratified), but it relies heavily on the “Scheme Request For Implementation“ (SRFI) process to fill out features. The larger portion of the R7RS “Large” standard is already ratified and published, so it is still useful even though it is not complete.

There are many Scheme implementations, but I recommend Guile, as it is almost completely R7RS-Small compliant, and has a ton of other useful features that come with it out of the box. So if you need, for example, a quick web server, or a way to search your filesystem, Guile has modules for that.

Another good batteries-included Lisp is Racket, which is a larger language built on top of Chez Scheme (an R6RS Standard Scheme implementation). You can easily install the R7RS Scheme language pack on Racket and write your code in Scheme as you read through the R7RS standard document.

Both Guile and Racket/CS (Chez Scheme) not only have many useful features, but compile to binary code that runs extremely fast for a high-level language.

Also, if you haven’t already, try to learn to use Emacs.