#schemelang — Public Fediverse posts

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

A person called Jonathan Kraut wrote an #assembler called Sassy in #R5RS #Scheme, which is used as the native code generating phase for the Larceny scheme compiler.

#tech #Software #SchemeLang #IA32 #FunctionalProgramming #Compiler

A person called Jonathan Kraut wrote an #assembler called Sassy in #R5RS #Scheme, which is used as the native code generating phase for the Larceny scheme compiler.

#tech #Software #SchemeLang #IA32 #FunctionalProgramming #Compiler

Apropos of nothing: Big thanks to Shiro Kawai for creating Gauche Scheme, which so far has been one of the best Scheme implementations I have used. It has worked well on every computer I have tried it on so far ({Linux, FreeBSD, MacOS} x {x86_64, i386, aarch64}). It is stable, very fast, and supports a large number of the more recent SRFIs (Scheme language extensions), it has very good compatibility with the R7RS language standard, and the Gauche REPL gosh is pretty easy to use as well.

I always run the REPL in R7RS mode, so gosh -r7 -I. -i . Scheme people, give it a try sometime if you haven’t already!

https://practical-scheme.net/gauche/

#tech #software #Scheme #R7RS #Lisp #SchemeLang #FunctionalProgramming #Gauche

Apropos of nothing: Big thanks to Shiro Kawai for creating Gauche Scheme, which so far has been one of the best Scheme implementations I have used. It has worked well on every computer I have tried it on so far ({Linux, FreeBSD, MacOS} x {x86_64, i386, aarch64}). It is stable, very fast, and supports a large number of the more recent SRFIs (Scheme language extensions), it has very good compatibility with the R7RS language standard, and the Gauche REPL gosh is pretty easy to use as well.

I always run the REPL in R7RS mode, so gosh -r7 -I. -i . Scheme people, give it a try sometime if you haven’t already!

https://practical-scheme.net/gauche/

#tech #software #Scheme #R7RS #Lisp #SchemeLang #FunctionalProgramming #Gauche

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

மானியக்கடன் (SUBSIDIZED) வழங்கும் முகாம் 2026 -திண்டுக்கல் மாவட்டம் நடைபெறும் நாள் 16.07.2026

More details : https://tinyurl.com/jfbuxk9r

#subsidyrestructuring #loans #subsidized #schemelang #BreakingNews #Tamilpost

Brings Erlang’s lightweight threads model to #ChezScheme and is programmable with ordinary #Scheme S-expressions. The most obvious use case for this would be a highly scalable web server that would be very easy to develop and upgrade on the fly without re-deploying after every change to the API.

Guile could probably do something like this using @wingo ‘s Guile Fibers. I could see this being ported to Guile as well.

EDIT: this was made by Guenchi. So that’s what she was working on all this time.

Two of her projects made the front page of HN twice today. I hope people don’t see her old, abandoned “Schemacs” project and confuse it with the one I am making.

#tech #software #SchemeLang #R6RS

Brings Erlang’s lightweight threads model to #ChezScheme and is programmable with ordinary #Scheme S-expressions. The most obvious use case for this would be a highly scalable web server that would be very easy to develop and upgrade on the fly without re-deploying after every change to the API.

Guile could probably do something like this using @wingo ‘s Guile Fibers. I could see this being ported to Guile as well.

EDIT: this was made by Guenchi. So that’s what she was working on all this time.

Two of her projects made the front page of HN twice today. I hope people don’t see her old, abandoned “Schemacs” project and confuse it with the one I am making.

#tech #software #SchemeLang #R6RS

#LuaLang is probably my fav imperative language and #RacketLang or #SchemeLang my fav functional one. Can't decide between Racket and Scheme, I want to like Scheme more but I have much more experience with Racket.

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

I was able to finish reading all of “The Genius of Lisp“ by @cdegroot and the whole book was as good as the free preview (chapter 8). I was able to speed-read through the detailed explanations of concepts I already knew, like tail recursion, garbage collection, the Y-combinator, Currying functions, and so on. But there were parts where I slowed down and read carefully, like the section on the Universal Turing Machine, and some of the details of the IBM-704 system architecture. Also the story of how the first Lisp implementation was created when one of McCarthy’s grad students implemented an M-Expression calculator, this was described in slightly more detail than what I recall McCarthy himself explaining in his 1960 paper — that or I had just forgotten those parts of the story.

The tone of this book reminds me a lot of popular physics books like Stephen Hawking’s “A Brief History of Time,” which was aimed more at general audiences than professionals. That said, there is a lot to enjoy about this book for professionals like myself as well. There are many good stories about the principals designers of Lisp throughout. The sections on the commercialization of Lisp for the first AI boom of the 1970s and it’s subsequent “AI winter,” were very interesting to read. And if you are a teacher, you might like how some of the concepts in the book are explained.

And I would definitely recommend this very strongly to 3rd-year high school students, or 1st and 2nd year college students, who are more genuinely curious about how computers work and want to know more than just how to make the next billion dollar app.

The next #LispyGopherClimate show with @screwlisp I look forward to talking about this book some more.

#tech #software #Lisp #ProgrammingLanguages #SchemeLang #Scheme #Clojure #Emacs #EmacsLisp #RetroComputing #LispyGopherClimateShow

I was able to finish reading all of “The Genius of Lisp“ by @cdegroot and the whole book was as good as the free preview (chapter 8). I was able to speed-read through the detailed explanations of concepts I already knew, like tail recursion, garbage collection, the Y-combinator, Currying functions, and so on. But there were parts where I slowed down and read carefully, like the section on the Universal Turing Machine, and some of the details of the IBM-704 system architecture. Also the story of how the first Lisp implementation was created when one of McCarthy’s grad students implemented an M-Expression calculator, this was described in slightly more detail than what I recall McCarthy himself explaining in his 1960 paper — that or I had just forgotten those parts of the story.

The tone of this book reminds me a lot of popular physics books like Stephen Hawking’s “A Brief History of Time,” which was aimed more at general audiences than professionals. That said, there is a lot to enjoy about this book for professionals like myself as well. There are many good stories about the principals designers of Lisp throughout. The sections on the commercialization of Lisp for the first AI boom of the 1970s and it’s subsequent “AI winter,” were very interesting to read. And if you are a teacher, you might like how some of the concepts in the book are explained.

And I would definitely recommend this very strongly to 3rd-year high school students, or 1st and 2nd year college students, who are more genuinely curious about how computers work and want to know more than just how to make the next billion dollar app.

The next #LispyGopherClimate show with @screwlisp I look forward to talking about this book some more.

#tech #software #Lisp #ProgrammingLanguages #SchemeLang #Scheme #Clojure #Emacs #EmacsLisp #RetroComputing #LispyGopherClimateShow

@badrihippo modern frameworks like React, Vue, and Van.js are all very similar, but I have not seen a consistent name for this family of frameworks. I have heard it called “The Elm Architecture,” because they are loosely based on how the Elm programming language originally did GUI programming in the browser. I have also heard it called the Model-View-Update paradigm. But most people just call it “React-like” or “Reactive Programming” because they are all similar to the very popular “React.js” framework.

Note that this should not be confused with Functional Reactive Programming (FRP), although the two are not completely different. As I understand it, React-like GUIs and FRP can both be implemented on top of a more powerful and more general computation model called “propagators” (here is the PDF of the original Propagators paper).

@dthompson wrote a really good blog post about FRP, propagators, and React-like frameworks.

I hope that helps, but I am not as well-versed in the theory of this stuff as I should be.

Oh, and I should say, before React-like took over the world wide web, GUI programming was mostly intertwined with Object Oriented Programming and design, so a good place to start might be to read up on Smalltalk OOP and GUI design.

#tech #software #GUI #ReactiveProgramming #FRP #Scheme #Haskell #SchemeLang #Propagators #ElmArchitecture #ReactJS #Smalltalk #OOP #ObjectOriented

@badrihippo modern frameworks like React, Vue, and Van.js are all very similar, but I have not seen a consistent name for this family of frameworks. I have heard it called “The Elm Architecture,” because they are loosely based on how the Elm programming language originally did GUI programming in the browser. I have also heard it called the Model-View-Update paradigm. But most people just call it “React-like” or “Reactive Programming” because they are all similar to the very popular “React.js” framework.

Note that this should not be confused with Functional Reactive Programming (FRP), although the two are not completely different. As I understand it, React-like GUIs and FRP can both be implemented on top of a more powerful and more general computation model called “propagators” (here is the PDF of the original Propagators paper).

@dthompson wrote a really good blog post about FRP, propagators, and React-like frameworks.

I hope that helps, but I am not as well-versed in the theory of this stuff as I should be.

Oh, and I should say, before React-like took over the world wide web, GUI programming was mostly intertwined with Object Oriented Programming and design, so a good place to start might be to read up on Smalltalk OOP and GUI design.

#tech #software #GUI #ReactiveProgramming #FRP #Scheme #Haskell #SchemeLang #Propagators #ElmArchitecture #ReactJS #Smalltalk #OOP #ObjectOriented

Looks like a fascinating read! They have provided chapter 8 as a PDF file downloadable gratis as a sneak-peek into the rest of the book, guess what it’s about:

Chapter 8: Sussman and Steel make Scheme

Awesome! I can’t wait to read that chapter, and then the rest of the book!

Details on the book homepage: https://berksoft.ca/gol/

#tech #software #Lisp #Scheme #SchemeLang #R7RS

RE: https://mstdn.ca/@cdegroot/116086771614712320

Looks like a fascinating read! They have provided chapter 8 as a PDF file downloadable gratis as a sneak-peek into the rest of the book, guess what it’s about:

Chapter 8: Sussman and Steel make Scheme

Awesome! I can’t wait to read that chapter, and then the rest of the book!

Details on the book homepage: https://berksoft.ca/gol/

#tech #software #Lisp #Scheme #SchemeLang #R7RS

RE: https://mstdn.ca/@cdegroot/116086771614712320

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

@momo cool!

Well then, please have a listen to the episodes of the #LispyGopherClimate podcast that me, @kentpitman and @screwlisp did these past few weeks:

• Kent Pitman presents his lisp condition system implemented for python
• Kent Pitman, Scott Zimmermann, Ramin Honary, Screwlisp: Lisp Conditions in Python
• Common Lisp condition handling lore
• Common Lisp condition system, code review of my programming example
• Common Lisp condition handling w/ Kent Pitman, Ramin Honary

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@momo cool!

Well then, please have a listen to the episodes of the #LispyGopherClimate podcast that me, @kentpitman and @screwlisp did these past few weeks:

• Kent Pitman presents his lisp condition system implemented for python
• Kent Pitman, Scott Zimmermann, Ramin Honary, Screwlisp: Lisp Conditions in Python
• Common Lisp condition handling lore
• Common Lisp condition system, code review of my programming example
• Common Lisp condition handling w/ Kent Pitman, Ramin Honary

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman regarding the discussion we had after the #LispyGopherClimate show ended, MiniKanren is logic programming language embedded in Scheme (sort-of like a Prolog implemented in Scheme and coded with S-expressions), and you can use machine leaning methods like neural networks to guide the search tree of the goal solver mechanism. This paper is an example of what I was talking about.

Even before LLMs were invented, MiniKanren was able to do program synthesis using purely symbolic logic. They developed a prototype called Barliman where you would provide example input->output pairs as constraints, and using a constraint solver, could generalize those examples to a function that generates any output for any input. As a simple example, you could give it the following input-output pairs:

1. () -> ()
2. (a) () -> (a)
3. () (a) -> (a)
4. (a) (a) -> (a a)

…and the constraint solver could determine that you are trying to implement the append function for lists and write the code automatically — without LLMs, using purely symbolic logic.

As you might expect, the solver could be very slow, or even diverge (never returning an answer). The paper I mentioned above talks about using neural networks to try to guide the constraint solver to improve the performance and usefulness of the results returned by the solver.

Now imagine applying this technique to other domains besides code generation or optimization, for example, auto-completion, or cache pre-fetching, and building it into a programmable computing environment like Emacs. You could have a tool like “Cursor,” but instead of using LLMs, it uses classical computing and constraint solvers, while taking a fraction of the amount of energy that LLMs use.

#tech #software #AI #LLM #MachineLearning #NeuralNetwork #ConstraintLogic #ConstraintSolver #LogicProgramming #Prolog #MiniKanren #Emacs #Lisp #Scheme #SchemeLang #ProgramSynthesis

@screwlisp @kentpitman regarding the discussion we had after the #LispyGopherClimate show ended, MiniKanren is logic programming language embedded in Scheme (sort-of like a Prolog implemented in Scheme and coded with S-expressions), and you can use machine leaning methods like neural networks to guide the search tree of the goal solver mechanism. This paper is an example of what I was talking about.

Even before LLMs were invented, MiniKanren was able to do program synthesis using purely symbolic logic. They developed a prototype called Barliman where you would provide example input->output pairs as constraints, and using a constraint solver, could generalize those examples to a function that generates any output for any input. As a simple example, you could give it the following input-output pairs:

1. () -> ()
2. (a) () -> (a)
3. () (a) -> (a)
4. (a) (a) -> (a a)

…and the constraint solver could determine that you are trying to implement the append function for lists and write the code automatically — without LLMs, using purely symbolic logic.

As you might expect, the solver could be very slow, or even diverge (never returning an answer). The paper I mentioned above talks about using neural networks to try to guide the constraint solver to improve the performance and usefulness of the results returned by the solver.

Now imagine applying this technique to other domains besides code generation or optimization, for example, auto-completion, or cache pre-fetching, and building it into a programmable computing environment like Emacs. You could have a tool like “Cursor,” but instead of using LLMs, it uses classical computing and constraint solvers, while taking a fraction of the amount of energy that LLMs use.

#tech #software #AI #LLM #MachineLearning #NeuralNetwork #ConstraintLogic #ConstraintSolver #LogicProgramming #Prolog #MiniKanren #Emacs #Lisp #Scheme #SchemeLang #ProgramSynthesis

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event)
  (let*-values (((state-ok modifiers) (event:get-state event))
               ((mod-bits)           (modifier-type->number modifiers))
               ((first-mod)           (car mod-bits)))
    (display "first modifier: ") (write first-mod) (newline)
    (display "is symbol? ") (write (symbol? first-mod)) (newline)
    (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline)
    #t
    ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask
is symbol? #t
eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event)
  (let*-values (((state-ok modifiers) (event:get-state event))
               ((mod-bits)           (modifier-type->number modifiers))
               ((first-mod)           (car mod-bits)))
    (display "first modifier: ") (write first-mod) (newline)
    (display "is symbol? ") (write (symbol? first-mod)) (newline)
    (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline)
    #t
    ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask
is symbol? #t
eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

— will be live in about 5 minutes.

https://emacsconf.org/2025/watch/dev

Questions can be posted to this live chat: https://pad.emacsconf.org/2025-schemacs

EDIT: Thanks for all the great questions everyone. It is so encouraging for me to see that there is so much interest in this project, it really keeps me motivated to keep working on it.

#tech #software #Emacs #SoftwareDevelopment #EmacsConf #EmacsConf2025 #SchemeLang #R7RS #Scheme

— will be live in about 5 minutes.

https://emacsconf.org/2025/watch/dev

Questions can be posted to this live chat: https://pad.emacsconf.org/2025-schemacs

EDIT: Thanks for all the great questions everyone. It is so encouraging for me to see that there is so much interest in this project, it really keeps me motivated to keep working on it.

#tech #software #Emacs #SoftwareDevelopment #EmacsConf #EmacsConf2025 #SchemeLang #R7RS #Scheme

@dpk (chair of the R7RS Scheme programming language standard working group) had designed a new, extensible #R7RS #Scheme pattern matcher library which generates optimal decision trees, and she has written a fantastic blog post about how it works: https://crumbles.blog/posts/2025-11-28-extensible-match-decision-tree.html

#tech #software #ProgrammingLanguage #SchemeLang

@dpk (chair of the R7RS Scheme programming language standard working group) had designed a new, extensible #R7RS #Scheme pattern matcher library which generates optimal decision trees, and she has written a fantastic blog post about how it works: https://crumbles.blog/posts/2025-11-28-extensible-match-decision-tree.html

#tech #software #ProgrammingLanguage #SchemeLang

"Naming and Logic" by @ArneBab is cool little booklet about Guile Scheme, see yourself: https://www.draketo.de/software/programming-scheme
#SchemeLang

"Naming and Logic" by @ArneBab is cool little booklet about Guile Scheme, see yourself: https://www.draketo.de/software/programming-scheme
#SchemeLang

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket

@jnkrtech you can read the original “Lambda Papers,” particularly AI Memo 349 “ Scheme: An Interpreter for Extended Lambda Calculus“ by Sussman and Steele where (I believe for the first time) continuation passing style was described in Section 3.4 “Continuation Passing Recursion”.

The rest of the “Lambda Papers” are all available on Wikisource.

#tech #software #FunctionalProgramming #Scheme #SchemeLang #R7RS #GerrySussman #GuySteele #AIMemo #MIT #LambdaPapers

@jnkrtech you can read the original “Lambda Papers,” particularly AI Memo 349 “ Scheme: An Interpreter for Extended Lambda Calculus“ by Sussman and Steele where (I believe for the first time) continuation passing style was described in Section 3.4 “Continuation Passing Recursion”.

The rest of the “Lambda Papers” are all available on Wikisource.

#tech #software #FunctionalProgramming #Scheme #SchemeLang #R7RS #GerrySussman #GuySteele #AIMemo #MIT #LambdaPapers

@plantarum hey, I’m the author of Schemacs.

Yes, there are Emacs-like editors written in a whole other language which make no attempt to clone Emacs Lisp.

• Lem is a text editor written in Common Lisp, but it relies on SBCL-specific features so you can only build it on SBCL. The nice thing about Lem is that you have access to the entire SBCL ecosystem, which is pretty close to Python in the number of useful packages you can use with it. It uses SDL2 to display. It at one point had an Electron front-end but I think they abandoned that.

• Edwin is a text editor written in Scheme, and comes bundled with the MIT Scheme implementation, which is compliant with the R7RS-Small Scheme standard. I believe it includes some of the original code used to teach the Scheme course at MIT back in the late 80s, and it is still minimally maintained even today. When I say “minimal,” I mean there have really been almost no new features added to it in like 30 years. It clones Emacs version 18 which was released back in 1992. All the maintainers do is make sure it runs on modern computers, and they otherwise leave it alone.

• Lite is a text editor implemented and scriptable in Lua on top of a minimal C-language kernel. This makes it more like Emacs, which is Lisp running on top of a small C-language kernel. I think you can even use libluagit5 to JIT-compile your Lua packages, which probably makes it extremely fast.

That said, I don’t find any of these especially useful because they lack the huge package ecosystem that exists for Emacs. Emacs “apps” that I use all the time include Magit (Git porcelain), Hyperbole (a cross-referencing app), TRAMP (remote access), Org-Mode, Mastodon-Mode, ERC chat, Elfeed (RSS), as well as the built-in Dired, Proced, and Shell modes, plus all the integrations Emacs has for shell utilities like Find, Grep, GPG, SSH, Tar, Zip, and so on. Without these, I would not have nearly as easy a time getting my work done.

That is why I have put so much effort into cloning Emacs Lisp. I want Emacs users to be able to use the Emacs code they have already written for themselves, and rely on, while being able to transition over to an editor with a better scripting language.

@llewelly

#tech #software #Emacs #ProgrammingEditor #CommonLisp #SchemeLang #R7RS #EmacsLisp #Lisp #ComputerProgramming

@plantarum hey, I’m the author of Schemacs.

Yes, there are Emacs-like editors written in a whole other language which make no attempt to clone Emacs Lisp.

• Lem is a text editor written in Common Lisp, but it relies on SBCL-specific features so you can only build it on SBCL. The nice thing about Lem is that you have access to the entire SBCL ecosystem, which is pretty close to Python in the number of useful packages you can use with it. It uses SDL2 to display. It at one point had an Electron front-end but I think they abandoned that.

• Edwin is a text editor written in Scheme, and comes bundled with the MIT Scheme implementation, which is compliant with the R7RS-Small Scheme standard. I believe it includes some of the original code used to teach the Scheme course at MIT back in the late 80s, and it is still minimally maintained even today. When I say “minimal,” I mean there have really been almost no new features added to it in like 30 years. It clones Emacs version 18 which was released back in 1992. All the maintainers do is make sure it runs on modern computers, and they otherwise leave it alone.

• Lite is a text editor implemented and scriptable in Lua on top of a minimal C-language kernel. This makes it more like Emacs, which is Lisp running on top of a small C-language kernel. I think you can even use libluagit5 to JIT-compile your Lua packages, which probably makes it extremely fast.

That said, I don’t find any of these especially useful because they lack the huge package ecosystem that exists for Emacs. Emacs “apps” that I use all the time include Magit (Git porcelain), Hyperbole (a cross-referencing app), TRAMP (remote access), Org-Mode, Mastodon-Mode, ERC chat, Elfeed (RSS), as well as the built-in Dired, Proced, and Shell modes, plus all the integrations Emacs has for shell utilities like Find, Grep, GPG, SSH, Tar, Zip, and so on. Without these, I would not have nearly as easy a time getting my work done.

That is why I have put so much effort into cloning Emacs Lisp. I want Emacs users to be able to use the Emacs code they have already written for themselves, and rely on, while being able to transition over to an editor with a better scripting language.

@llewelly

#tech #software #Emacs #ProgrammingEditor #CommonLisp #SchemeLang #R7RS #EmacsLisp #Lisp #ComputerProgramming

Yes it is, I can tell you from experience. Of course, I was never under any illusion that it would be easy.

@kana , a.k.a. “Gudzpoz,” wrote a blog post which was shared on Lobste.rs, and they kindly mention my own Emacs clone Schemacs, though they refer to the old name of it “Gypsum” because they are citing my EmacsConf 2024 presentation done before the name changed.

It is a pretty good post going over some of the odd details about how Emacs edits text, e.g. the character range is from 0x0 to 0x3FFFFFF rather than the Unicode standard range from 0x0 to 0x10FFFF, issues with using a gap buffer as opposed to a “rope” data structure, attaching metadata (text properties) to strings to render different colors and faces, and issues with Emacs’s own unique flavor of regular expressions in which the \= symbol indicates matching on the point in the buffer. (I did not know about that last one!)

Apparently, they know these things because they are also working on their own clone of Emacs in Java for the JVM called Juicemacs (the name “Juice” upholding the theme of Java-based applications being named after drinks), and I deduce that their approach is to read through the Emacs C source code to ensure better compatibility. This is now the fourth modern Emacs+EmacsLisp clone that is still under active development that I know of, fascinating work!

My approach is to clone Emacs well enough to get it to pass regression tests, and I don’t read the C source code, I do black-box testing (because those tests become regression tests for my own source code).

Also, the goal with the Schemacs project is more to provide a Scheme-based Emacs that is backward-compatible with GNU Emacs. You use Schemacs because you want to program it in Scheme, not Emacs Lisp, but Emacs Lisp is there for you so you can still use your Emacs config. As a result, I will ignore a lot of these fussy details of the GNU Emacs implementation unless it is going to prevent regression tests from passing.

#tech #software #Emacs #GNUEmacs #Schemacs #EmacsLisp #Lisp #Java #Scheme #R7RS #SchemeLang #LispLang #JavaLang

I made a thing! It's not much to look at, but the important thing is how it was made. This is the first time I've been able to program a "game" in Scheme and get it running in a web browser! This opens up so many possibilities! :blobcataww:

https://croisant.net/projects/crunch-sdl3-demo/demo.html

I'm planning to do a full write-up once I've developed the concept further. But briefly, the Scheme code is compiled to C with CRUNCH, then to WASM with emscripten. It uses SDL3 for the graphics. What is extra exciting is that CRUNCH generates really portable and performant C code, so this same technique could also be used to develop native PC games, mobile games, or even console games!

#SchemeLang #GameDev #WASM