Maybe a Common Lisp core with an Emacs frontend running it in https://www.gnu.org/software/emacs/manual/html_mono/cl.html?
replyWhy not just use the best known emacs lisp core, then? Like say emacs.
replyTo allow it to run on other lisp dialects as well.
reply(I’m just trying to defend GP’s point – I’m not a heavy lisp user myself, tbh.)
Portability across Lisp dialects is usually not a thing. Even Emacs Lisp and Common Lisp which are arguably pretty close rarely if ever share code.
replyYou could make a frontend for dialect A to run code from dialect B. Those things have been toyed with, but never really took off. E.g. cl in Emacs can not accept real Common Lisp code.
I'm not arguing against the idea, I'm just curious how it would work because I see no realistic way to do it.
Gotcha. Too bad – I was hoping there was at least some (non-trivial) subset you can run on both :(
replyAny idea why is it not a thing? Is this level of interop not practical for some reason?
Lisp dialects have diverged quite a bit, and it would be a lot of work to bridge the differences to a degree approaching 100%. 90% is easy, but only works for small trivial programs.
replyI say this, having written a "95%" Common Lisp for Emacs (still a toy), and successfully ran an old Maclisp compiler and assembler in Common Lisp.
https://github.com/larsbrinkhoff/emacs-cl
https://github.com/PDP-6/ITS-138/blob/master/tools/maclisp.l...
still in their main doc https://www.gnu.org/software/guile/manual/html_node/Emacs-Li...
replyHaving read that, I'm even less convinced it's not more than a toy.
replyyou could probably use the unexec tooling
replyI don't see how unexec would help with "decoupling the core from Emacs" since the core is written in Emacs Lisp.
replyyou could make a standalone executable. I was assuming that people didn't want to start emacs to run it. if its just because...emacs is just morally offensive and one doesn't even want it running under the covers, I dont how to help you.
replyEmacs is needed because it provides Emacs Lisp.
reply