Emacs Lisp's Future
lists.gnu.org
Emacs Lisp's Future
1–10 of 160 posts
Re: Emacs Lisp's Future
#2Re: Emacs Lisp's Future
#3Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.
Re: Emacs Lisp's Future
#4Re: Emacs Lisp's Future
#5"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
#6"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
#7I 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
Re: Emacs Lisp's Future
#8It'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
#9I've got the impression that there is more Common Lisp code and programmers around than guile.
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
#10I'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.
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.