Live data from Hacker News

Emacs Lisp's Future

lists.gnu.org

1–10 of 160 posts

Re: Emacs Lisp's Future

#3
"Lack of some features, most notably FFI and concurrency."

Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.

Re: Emacs Lisp's Future

#5
post #3

"Lack of some features, most notably FFI and concurrency." Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.

It seems your libffi has been used in Guile since 1.9.8, so does that mean Guile does support FFI and concurrency?

Re: Emacs Lisp's Future

#6
post #5
post #3

"Lack of some features, most notably FFI and concurrency." Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.

It seems your libffi has been used in Guile since 1.9.8, so does that mean Guile does support FFI and concurrency?

The quote is about Emacs.

Re: Emacs Lisp's Future

#7

I sent a note about using an elisp-on-llvm solution. Someone had done the work already, it appears: https://github.com/boostpro/emacs-llvm-jit

There's no way they'd do that. There's a rift because of LLVM's licensing philosophy: https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

Re: Emacs Lisp's Future

#8
Given all the reworks of software projects that have a) been started b) then delayed c) then delayed more, "because this time we'll make it perfect" and d) then failed to gather traction because of incompatibilities, it's my humble guess that the only way would be to continue ELisp as it is and slowly rework the compiler/interpreter and the runtime into a more modern codebase, and add missing features such as thread/process based concurrency. Guile, Clojure, Common Lisp or whatever language are going to basically restart Emacs from scratch, no matter how well they're coated with compatibility macros.

It's better to create slight incompatibilities gradually (so that packages can catch up in some humane timeframe). I could imagine the ELisp runtime being intertwined with the Emacs C code badly enough that making radical changes to it would seem "impossible", just like in the CPython codebase it is considered impossible to ditch GIL and modernise the code. But those kind of comments are often excuses because people are lazy and it's nicer to write new code.

Re: Emacs Lisp's Future

#9

I've got the impression that there is more Common Lisp code and programmers around than guile.

Literally dozens more.

Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.

Re: Emacs Lisp's Future

#10

I've got the impression that there is more Common Lisp code and programmers around than guile.

Literally dozens more. Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.

The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s.

GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile run properly (which took them 25 years and still nobody is using it) and the two Lisps were basically orphaned.

The latest effort of guile-ifying Emacs is more pushed by the Guile guys, in order to attach themselves to an already existing killer app (emacs) and to basically force more and more people to use Scheme, because nobody is doing it voluntarily.

The Emacs guys, as you see from the post, are not _really_ excited about the idea of switching to another _language_. They want FFI, multithreading, etc, but they do not necessarily want Scheme. Actually they dont want Scheme at all, adopting Scheme would be just a price to get FFI, etc.

Of course the proper way would be to go Common Lisp. Elisp is and has always been a subset of Common Lisp, and they've had a Common Lisp compatibility layer for decades, and a lot of packages use it. The problem is simply highly political. You'd have to confront RMS, and you'd have to finally get rid of Guile's "official GNU extension language" status.

Post reply on HN