emacs roadmap

emacs roadmap

[Tony Day]

Is there a long term roadmap for emacs research and development that
someone could point to?  Having done my homework I find nothing out
there except rumour and myth.  For instance:

- Is multi-threading coming to emacs 25?
- Is there realistic support for replacing elisp with guile?  Is that
  considered possible even?
- If elisp is the future, what type of changes are envisaged?  
  - double escape regex fix? 
  - lexical closures (to support no namespaces)?
  - first-class print for functions?

More generally, when can we get turtles all the way down and enjoy the
return of the symbolic machine?

Re: emacs roadmap

[Noah Lavine]

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

Hello,

I know very little about Emacs development, but I'm a Guile developer, so
let me see if I can explain that situation: Guile used to be an embeddable
implementation of the Scheme programming language, and there was a plan to
use Guile in Emacs and rewrite everything in Guile. Guile (since 2.0) is
now an embeddable VM and a collection of compilers to that VM. It can run
Elisp in the same way that Emacs can. There has been talk of using the
Guile VM in Emacs.

As for realism - it's certainly a realistic possibility technically. The
work would mostly be in the C part of Emacs - changing lisp.h, the
interpreter, and similar things. The low-level Elisp that implements the
compiler would also change, but almost all Elisp would be untouched. There
would be some technical advantages, and I can think of one possible
technical downside. (I'll write more about those if anyone's interested.)

But I think the biggest question is sociological - do the Emacs developers
*want* to use Guile? Is the benefit of work-sharing worth the loss of some
amount of control over their language implementation? I can't answer that.

I hope this is helpful,
Noah Lavine


On Sun, Dec 16, 2012 at 5:25 PM, Tony Day <tonyday567@gmail.com> wrote:

> Is there a long term roadmap for emacs research and development that
> someone could point to?  Having done my homework I find nothing out
> there except rumour and myth.  For instance:
>
> - Is multi-threading coming to emacs 25?
> - Is there realistic support for replacing elisp with guile?  Is that
>   considered possible even?
> - If elisp is the future, what type of changes are envisaged?
>   - double escape regex fix?
>   - lexical closures (to support no namespaces)?
>   - first-class print for functions?
>
> More generally, when can we get turtles all the way down and enjoy the
> return of the symbolic machine?
>
>

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

Re: emacs roadmap

[Stefan Monnier]

> Is there a long term roadmap for Emacs research and development that
> someone could point to?  Having done my homework I find nothing out
> there except rumour and myth.  For instance:

There isn't a very clear roadmap, indeed.

> - Is multi-threading coming to emacs 25?

Maybe not multi-threading, but I do hope to get some kind of concurrency
in there, yes.

> - Is there realistic support for replacing elisp with guile?  Is that
>   considered possible even?

Replacing Elisp with another language seems rather unlikely.  As for
replacing the Elisp implementation with another one, e.g. based on the
Guile VM, that is indeed possible.
But there's nothing concrete on the horizon.

> - If elisp is the future, what type of changes are envisaged?  
>   - double escape regex fix? 

Would be nice, but again: nothing concrete on the horizon.

>   - lexical closures (to support no namespaces)?

Lexical closures are supported natively since Emacs-24.  Namespaces are
another beast altogether, and there's not much on the horizon there either.

>   - first-class print for functions?

Not sure what that would be.

> More generally, when can we get turtles all the way down and enjoy the
> return of the symbolic machine?

My experience with Lisp machines has been fairly limited, so I'm not
sure what would be the thing that is most sorely missing.


        Stefan

Re: emacs roadmap

[Tom Tromey]

>>>>> "Tony" == Tony Day <tonyday567@gmail.com> writes:

Tony> Is there a long term roadmap for emacs research and development that
Tony> someone could point to?  Having done my homework I find nothing out
Tony> there except rumour and myth.  For instance:

Tony> - Is multi-threading coming to emacs 25?

I don't know about Emacs 25, but I did manage to merge trunk to the
concurrency branch today.  If you're interested you could try it out.

I still haven't done any development work on it since the last time I
asked a question here.  All the big features work though.

Tony> More generally, when can we get turtles all the way down and enjoy the
Tony> return of the symbolic machine?

It is difficult.

Tom

Re: emacs roadmap

[Tony Day]

On 17 Dec 2012, at 09:37, Noah Lavine <noah.b.lavine@gmail.com> wrote:

> Guile used to be an embeddable implementation of the Scheme programming language, and there was a plan to use Guile in Emacs and rewrite everything in Guile. Guile (since 2.0) is now an embeddable VM and a collection of compilers to that VM. It can run Elisp in the same way that Emacs can.

Thanks - that helps tremendously.  I was mixing up old-school discussions of guile with Guile 2.0.  Lua support coming - wow!

> There has been talk of using the Guile VM in Emacs.
> 

Where would that talk be located?

> As for realism - it's certainly a realistic possibility technically. The work would mostly be in the C part of Emacs - changing lisp.h, the interpreter, and similar things. The low-level Elisp that implements the compiler would also change, but almost all Elisp would be untouched. There would be some technical advantages, and I can think of one possible technical downside. (I'll write more about those if anyone's interested.)

I'd be very interested in your views of both the advantages and disadvantages, for one.

Re: emacs roadmap

[Tony Day]

> 
> I don't know about Emacs 25, but I did manage to merge trunk to the
> concurrency branch today.  If you're interested you could try it out.

Thanks Tom, I'll check it out for sure.  There's a whole heap of workflow processes that I keep outside of emacs solely because of concurrency.

Re: emacs roadmap

[Tony Day]

> Lexical closures are supported natively since Emacs-24.  Namespaces are
> another beast altogether, and there's not much on the horizon there either.

Ok, so now I understand defvar, lol.  Not much use of lexical scoping in the wild - this was all I could find: http://github.com/nicferrier/elnode


>>  - first-class print for functions?
> 
> Not sure what that would be.
> 

ELISP> (defun foo()
    '(1 2 3))

ELISP> (as-string 'foo)

(defun foo()
    '(1 2 3))

Would be very useful for debugging.

>> More generally, when can we get turtles all the way down and enjoy the
>> return of the symbolic machine?
> 
> My experience with Lisp machines has been fairly limited, so I'm not
> sure what would be the thing that is most sorely missing.

Tounge was slightly in cheek.  What annoys me 100 times a day is having to switch away from the emacs environment to a browser and I was imagining that the technical difficulties involved in getting a decent browser rendering might coincide with the point at which C is needed to get closer to the *nix machine metal.  I'm half hoping that things like guile 2 pushing lisp further down the chain might one day lead to an emacs os (a personal preference not a recommendation). 

Re: emacs roadmap

[Stefan Monnier]

>> Lexical closures are supported natively since Emacs-24.  Namespaces are
>> another beast altogether, and there's not much on the horizon there either.
> Ok, so now I understand defvar, lol.  Not much use of lexical scoping in the
> wild - this was all I could find: http://github.com/nicferrier/elnode

Use of lexical-binding restricts the code to Emacs-24, so it's
understandably not used very much in the wild yet.  But if you grep for
`lexical-binding:' in the emacs/lisp/**/*.el or elpa/packages/**/*.el
files, you'll see that such code does exist.

>>> - first-class print for functions?
>> Not sure what that would be.

ELISP> (defun foo () '(1 2 3))
ELISP> (as-string 'foo)
> (defun foo() '(1 2 3))
> Would be very useful for debugging.

(symbol-function 'foo) gives you something pretty close for
interpreted functions.  For byte-coded functions, we don't keep enough
info to get this data, but `C-h f foo RET' should give you a hyperlink to
the function's actual source code.

> Tounge was slightly in cheek.  What annoys me 100 times a day is having to
> switch away from the emacs environment to a browser and I was imagining that
> the technical difficulties involved in getting a decent browser rendering
> might coincide with the point at which C is needed to get closer to the *nix
> machine metal.  I'm half hoping that things like guile 2 pushing lisp
> further down the chain might one day lead to an emacs os (a personal
> preference not a recommendation). 

Implementing a browser in Elisp is of course problematic because of the
lack of efficiency of Elisp.  But even if Elisp/Guile were super
efficient, keeping up with the web standards is a big job in itself, so
we don't want to go there anyway, and instead we'd want to rely on
external libraries.  Still, a close integration between those libraries
and Emacs is a non-trivial problem.  A lot of people would be happy to
see some progress on this front, indeed.


        Stefan