Preview: portable dumper

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

Spending time on Guile Emacs? (was: Preview: portable dumper)

[John Wiegley]

>>>>> "TG" == Tobias Gerdin <tgerdin@gmail.com> writes:

TG> So I am wondering if the time used to play catch-up with modern Lisps
TG> would not be better spent by integrating Guile?

I really think this just comes to down to who is willing to do that work?
Guilemacs has made a lot of progress in the last few years, but it still
hasn't garnered much attention yet.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Spending time on Guile Emacs?

[Daniel Colascione]

On Wed, Nov 30 2016, John Wiegley wrote:
>>>>>> "TG" == Tobias Gerdin <tgerdin@gmail.com> writes:
>
> TG> So I am wondering if the time used to play catch-up with modern Lisps
> TG> would not be better spent by integrating Guile?
>
> I really think this just comes to down to who is willing to do that work?
> Guilemacs has made a lot of progress in the last few years, but it still
> hasn't garnered much attention yet.

Did we ever address the mismatch between Guile strings and Emacs ones?
We can't depend on everything being valid UTF-8.

Re: Spending time on Guile Emacs?

[Stefan Monnier]

> Did we ever address the mismatch between Guile strings and Emacs ones?
> We can't depend on everything being valid UTF-8.

Guile-Emacs has an "easy" solution for this: there are 2 kinds of strings,
the Scheme strings and the Emacs strings.


        Stefan

Re: Spending time on Guile Emacs? (was: Preview: portable dumper)

[Christopher Allan Webber]

John Wiegley writes:

>>>>>> "TG" == Tobias Gerdin <tgerdin@gmail.com> writes:
>
> TG> So I am wondering if the time used to play catch-up with modern Lisps
> TG> would not be better spent by integrating Guile?
>
> I really think this just comes to down to who is willing to do that work?
> Guilemacs has made a lot of progress in the last few years, but it still
> hasn't garnered much attention yet.

John is right.  The work is there, I even rebased the Guile repo not too
long ago (it's wip-elisp in Guile's repo), but it needs someone to step
up and do the work.

Notably this would bring a lot of the things people have been asking for
(an FFI, efficiently compiled code and when Guile gets it (it's on the
Guile agenda), JIT compilation) along the way.

I think it's worth persuing.  Someone needs to do the work though... it
definitely needs to be incubated to stability further to prove itself. :)

Tobias, are you interested in working on it?