Preview: portable dumper

[Tobias Gerdin]

Since some years there has been the intention of switching to Guile for Emacs' 
Lisp needs. As I understand it one of the major issues to be resolved is the 
lack of Guile unexec support, so would it not be prudent to consider the 
implications for a (possible) future Guile Emacs? Something along the lines of 
what Eli proposed (the ”one big .elc”approach) is a requested feature by one of 
the Guile maintainers[1].

During the last few years there has been a fair amount of work put in to 
modernise Emacs Lisp (lexical binding probably being the most notable 
accomplishment). Still, Emacs Lisp has a long way to go to match a high-quality 
Scheme implementation.
So I am wondering if the time used to play catch-up with modern Lisps would not 
be better spent by integrating Guile? There seems to have been a lot of focus 
on performance in Guile the last few years and it also comes with good 
concurrency support (which has been another area of focus in Emacs). Recently 
another concurrency mechanism which may be a better fit than threads has also 
appeared in Guile [2]. There has also been discussion of making it easier for 
recruit new Emacs developers. I believe that adopting Guile and Scheme would be 
the single most important step towards this aim. 

Given the number of talented hackers in the Emacs and Guile community I would 
say that making Guile-Emacs a reality is a definitely possible. However, it 
would probably require to work together actively towards this goal, as opposed 
to fragmented hacking by single developers.

-Tobias

[1]: https://wingolog.org/archives/2016/02/04/guile-compiler-tasks
[2]: https://github.com/wingo/fibers