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?

Re: Spending time on Guile Emacs?

[Tobias Gerdin]

>> 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.

In addition there is the text properties support. Unless one unifies the two representations (perhaps via a compile-time flag if Emacs will be statically linked with Guile) I think the challenge is to make it easy and not too expensive to convert between them.

-Tobias

Re: Spending time on Guile Emacs?

[Eli Zaretskii]

> From: Tobias Gerdin <tgerdin@gmail.com>
> Date: Thu, 1 Dec 2016 21:48:05 +0100
> 
> In addition there is the text properties support. Unless one unifies the two representations (perhaps via a compile-time flag if Emacs will be statically linked with Guile) I think the challenge is to make it easy and not too expensive to convert between them.

Why would Guile want to know about text properties?  What would it do
with them?

AFAIU, Guile should receive only the text part of the Emacs strings,
with or without encoding conversion (probably with, because there are
some quirks in Emacs internal representation of text that Guile
neither can nor should care about).

As for statically linking Emacs with Guile, I'm not sure it's a good
idea, as Guile is a very large library.

Re: Spending time on Guile Emacs?

[Tobias Gerdin]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

2016-12-02 8:20 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Tobias Gerdin <tgerdin@gmail.com>
> > Date: Thu, 1 Dec 2016 21:48:05 +0100
> >
> > In addition there is the text properties support. Unless one unifies the
> two representations (perhaps via a compile-time flag if Emacs will be
> statically linked with Guile) I think the challenge is to make it easy and
> not too expensive to convert between them.
>
> Why would Guile want to know about text properties?  What would it do
> with them?
>

If one would like to be able to use the standard Scheme string manipulation
procedures I believe Guile would need to know about the text properties
since they should be preserved. One option would be to have special
implementations of these when called from Emacs, or just provide some other
Emacs-only string library alltogether.


> AFAIU, Guile should receive only the text part of the Emacs strings,
> with or without encoding conversion (probably with, because there are
> some quirks in Emacs internal representation of text that Guile
> neither can nor should care about).
>

Right, keeping string Unicode-only makes a lot of sense for Guile in
general.

As for statically linking Emacs with Guile, I'm not sure it's a good
> idea, as Guile is a very large library.
>

Dynamically linked would be best of course, provided one could work out the
other issues without resorting to any compile-time configuration.

[-- Attachment #2: Type: text/html, Size: 2191 bytes --]