The big advantage of eLisp is it inherited the capability of changing a running program while it is running from earlier lisps. Schemes, including Racket, generally can't do that.

So with eLisp, it's natural to allow editing config.el and reloading without restarting Emacs. It's possible to do in languages outside the Common Lisp branch of the tree of life. But it's a Turing tarpit. The default is changing a program requires killing the existing instance and restarting. That's fine for a distributed application because there are lots of instances. In a word processor, a single thread is a reasonable abstraction.

Lots of schemes do let you change running programs and elisp doesn’t support the various crazy CLOS things for dealing with instances of classes since redefined.

If scheme where so different from elisp, no one would have bothered trying to make guilemacs yet here we are.

I think this was sort of the idea of emacs-on-guile, guile supports elisp, but also supports scheme and there are other languages availble too like python[0] and lua [1]

[0]https://gitlab.com/python-on-guile/python-on-guile/ [1]https://gitlab.com/NalaGinrut/guile-lua-rebirth

This is a really great idea, IMO. I don't know Racket very well but I'd be very willing to learn just for this project. You should get an interest check going on Reddit or wherever Racket users frequent most.

That's my dream! Do you know of any existing efforts towards it? I don't know much about Racket, how would #lang Python thing work (i.e. in terms of calling foreign functions etc)?

You could probably use Edwin[1][2] as a starting point. MIT Scheme is close enough to Racket that you could probably do some automated source-to-source translations, or use "#lang sicp"[3] or "#lang r5rs"[4] within Racket.

Haven't tried it, but it would be interesting.

[1] https://www.gnu.org/software/mit-scheme/documentation/mit-sc...

[2] https://github.com/jaseemabid/mit-scheme/tree/master/src/edw...

[3] https://docs.racket-lang.org/sicp-manual/SICP_Language.html

[4] https://docs.racket-lang.org/r5rs/r5rs-mod.html

As to `#lang python` interop with Racket, it's possible, but the farther a language's semantics and object model differ from Racket, the harder and less pleasant it is to build and use in practice. In other words, you need converters between runtime values between Racket and Python when their semantics differ. For example, Python strings are instances of Python's string class, with a bunch of methods, and you can mutate the string class at runtime. They are very different from Racket's strings. Then you have all the differences in core reduction semantics, how concurrency and parallelism is handled, etc, and there are a lot of differences to smooth over.

There is a project called PyonR (https://github.com/pedropramos/PyonR) that implements Python 2.7 as a Racket #lang, but it hasn't been developed for a while, and I'm not sure how interoperable it actually is. It certainly isn't to the point where you could pull in your favorite Python package from PyPI to use in Racket, but it does claim that you can use Racket functions in your Python code at least. The hardest part just using PyPI packages is probably that many of the most important Python packages lean on Python's C FFI, which is a large extra hurdle, though there are many worthwhile packages that are pure Python code.

The most successful Racket #langs are languages that fit a particular domain or style of programming better than basic Racket, but that lean on Racket's core semantics and object types as a building block rather than something to be constantly slightly different from in ultimately unimportant ways. While working with Racket, these languages may be very different from the core Racket language, such as documentation languages (scribble), logic languages (datalog), shells (rash), database query languages, etc. If you just wanted to let people write new code for their editor in a language that looks and feels like Python alongside Racket and its #langs, it would be a much easier project to make a language with Pythonic syntax (syntax is shallow), easy constructors for Python-like lists and such (just a few custom datatypes), and a Python-like way of providing generic operators (eg. __magic_method__), etc, but otherwise with semantics closer to Racket's. Frankly, you would end up with a better language than Python anyway, with powerful features that most Pythonistas haven't dreamt of. (Bias revealed!) But I do dream of having a `#lang python` implementation good enough to just use Python packages in a pinch when Racket doesn't have an equivalent package. It's possible, but it's a big enough project and there is little enough manpower in the Racket world that nobody is seriously working on it.

I agree with you. In a perfect world you would be able to drop in Python code and only have to add a #lang Python at the top of it. But realistically I think it would be closer to what you were saying about creating a pythonic language.

So maybe the practical solution is to have a language that looks like Python, Java, Ocaml, etc. I'm not sure how many #langs you would need to make the majority of programmers feel comfortable but I think even implementing a few would be a huge step up in accessibility than what we currently have.

I intend to write at least a small version of this. There are a couple of existing “Emacs-in-Racket” projects which I may borrow code or ideas from. The older one is https://github.com/tonyg/rmacs, which runs but is not in a state where it's really usable for anything, and there is a newer https://github.com/soegaard/remacs which I have never gotten to run on a Linux system.

Essentially my plan is to make an Emacs-like editor with a line-editor interface for my embedded-in-Racket shell, Rash (https://rash-lang.org). Of course, I will also make a TUI interface, like terminal Emacs, and while I probably won't write it myself, I would leave it open to have a GUI interface as well, and generally be embeddable in arbitrary Racket programs that need an editor component. While I don't have the time or will to really make something that could compete with Emacs as a general-purpose editor, or seriously try to implement a `#lang elisp` to give Emacs compatability, I think building an Emacs-like editor in Racket with an actual function that people will use (better line editing for Racket, Rash, other Racket languages) could give people enough reason to hack on it themselves that it could grow and be useful at least as a line editor.

Additionally, I have some ideas on plugin sandboxing I would like to try out. In other words, while I would obviously just have an interpreter with which you could run arbitrary code to modify the editor, like Emacs but with Racket code in any #lang, I also may add an API using Racket's sandboxing features so that you can run extensions with limited, explicit privileges. I want to be able to run extension code written by internet randos without auditing it, but trust that it won't steal my ssh keys and such.

That said, I'm trying to finish my PhD and I haven't even done any direct work on Rash itself for a while. My advisor says “your editor should be your first side project after graduating”, and I agree with him. So my Emacs-in-Racket may yet be eternal vaporware, and even if it isn't, advanced features that I want might not make the cut when I actually determine how much time I can commit to it. We'll see.

At any rate, even if other people do it first and better, I'm likely to make a small version of this some day just because I want to -- I've already written my own terminal emulator in Racket (which works but is slow, and I don't recommend anybody use it), and my own shell in Racket (which is awesome, and I do recommend people use it, at least for scripting, and eventually I will develop it further [contributors welcome!]), so naturally I need to make my own editor as well.

Rash looks great. You honestly sound way more qualified to do this than I do. It makes me happy to hear that so many people have had the same idea/wanted the same thing. Racket is uniquely positioned to do this. I would definitely be interested in the GUI portion of this. Who knows maybe one day something will appear in a Racket News blog post ;)

It was a trend not long ago to use org as a form of literate config. Not sure if it is still possible, but the general idea is similar.