Comment by yason | Hacker News Reader

Comment by yason | Hacker News Reader

Parent Full thread

Given all the reworks of software projects that have a) been started b) then delayed c) then delayed more, "because this time we'll make it perfect" and d) then failed to gather traction because of incompatibilities, it's my humble guess that the only way would be to continue ELisp as it is and slowly rework the compiler/interpreter and the runtime into a more modern codebase, and add missing features such as thread/process based concurrency. Guile, Clojure, Common Lisp or whatever language are going to basically restart Emacs from scratch, no matter how well they're coated with compatibility macros.

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

As a programming language aficionado, I get really excited by the idea of Guile-Emacs. Yet I couldn't agree more with what you just said. Breaking Emacs Lisp would be a disaster, evolving it slowly to add support for the desired features seems a much more reasonable choice. Not only on the side of package maintainers but also on emacs developer's: at least any effort is worthwhile, since it will be a little step of improvement on actual Emacs rather than starting or continuing a project which has more chance to be abandoned at some point than to merge into the main Emacs branch.

If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.

Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.

>Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway

Guile is already a general VM meant to support many different languages, not only Scheme. I think it's a very clean solution to use Guile's efficient VM, and I don't think minimalistic is a useful criterion.

Are you sure that Richard Stallman does not like Common Lisp?

Several years ago he asked me about the possibility of my releasing my out of print Common Lisp book (published by Springer-Verlag) under the GNU documentation license. I would have liked to do that but I couldn't find my manuscript word processing files.

I found some of the messages I was thinking of (this stuff is scattered across many years of debates, so there are probably others).

Clisp maintainer on how loading Elisp into clisp was a weekend's work (2002, but talking about work from "a couple of years ago"): https://lists.gnu.org/archive/html/emacs-devel/2002-08/msg00...

Stallman arguing "Common Lisp is extremely complicated and ugly" and "would bloat Emacs terribly" (2010): https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

+1 thanks for those links. You are probably correct about Richard's view of Common Lisp.

Too often it seems RMS is why GNU can't have nice things.

If he made the opposite call, and adopted CLisp, you'd be complaining about him anyway, in a thread about some unexpected compatibility problem or whatever.

It gets tiresome even to watch.

Uh, no. Common Lisp is sensible. It's multi-implementation and several of the implementations are JVM levels of fast, while others are highly portable. There's a community, standards, and libraries. It's not where the froth of lisp experimentation is happening, but it's effective and a known quantity.

You are aware though that without RMS we wouldn't have Emacs?

RMS would never let practicality get in the way of ideology.

The GNU/RMS is best because you're free! (As long as your computing needs are a text editor, compiler, and some unix system utils)

That's why I believe their FFI plans are doomed.

We implemented FFI's for emacs over the last decades, but RMS always strongly opposed it, because you could call windows DLL's then. gtk-emacs e.g.

RMS is fine with an FFI as long as you cannot use it to inject non-free code. This is usually done by requiring an exported symbol saying that the code is GPL compatible. GCC does it this way:

https://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html

But you cannot call that a FFI then. A FFI is the abbrevation for "Foreign Function Interface", not "Friendly Function Interface". FFI's are not sugar coated.

Guile can run elisp already, IIRC. There's no compatibility issue, it would just be a runtime change. And then you'd get Guile's VM, which is very nice and also polyglot(tic?). Guile is a language-agnostic VM, not a language itself, and a frontend already exists for elisp.

> There's no compatibility issue

That's not really true, is it though? Scheme '(), #f and so forth...

As I said in my comment,

>Guile can run elisp already

Guile already interprets Elisp.

Elisp can run unmodified on Guile.

Guile, the virtual machine, contains a front-end for Emacs Lisp.

المكر ينفذ أصلا إيماكس اللثغة.

Guile jatorriz exekutatzen emacs Lisp.

It is true there are no compatibility issues because Guile is an implementation of Emacs Lisp.

From the same thread https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00...

> It's not a 100% drop-in replacement, that's true…(eq foo t) should always work. (eq foo nil) will only work if that `nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then you need to make that (not foo) or (null foo) (both works in both cases); anything but (eq foo nil).

Note that using the `not' and `null' functions instead of comparing equality to `nil' is good coding style anyway.

That seems to imply that the problem is in the Scheme/Elisp interface, not in Guile's execution of pure Elisp.

Right. Javascript used to be slow, but instead of bemoaning how slow it was and thinking maybe they should change languages, people made Javascript fast. If it can be done with Javascript, why not Elisp?

Because Javascript has huge players like Google, Microsoft and Mozilla behind it that throw insane ressources at it to compete for performance, whereas EMacs is fast enough for most of its users and has no big companies interested in its performance.

Hmm. I wonder whether a Javascript vm could be used for Elisp. Of course Javascript is lexically scoped but there's a way to hack around that: http://stackoverflow.com/questions/10060857/is-it-possible-t...

Of course there'd be no point if emacs were fast enough, but there seems to be a significant number of people who feel it's not.

I agree with all of this as an emacs user, but I wonder whether this sets up emacs to be replaced by something that uses a more popular extension language, like Atom. Won't happen in the next 5 years, but 10 years down the line, being based on JavaScript might look like a great decision.

I love lisp but I don't see much interest in it and have had coworkers tell me it keeps them away from emacs. Which is a bit sad...

I think emacs lisp is a great extension language. There's not much syntax, and it has the important functionality baked in. IMO anyone that says they don't use Emacs because they don't like Lisp is someone that would not use Emacs no matter what.

Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.

Agreed. This is busy work. If emacs were a pay for commercial product then this wouldn't be considered because emacs is still proving itself economically viable.

Considering how intricately it is integrated into a lot of people's lives this is silly.

It's fine sitting on a an academic pedestal but some of us have to live in the real world.

Also I'm not sure how the maintainer failed to address your suggestion as it seems the most logical... which makes me worry this is an academic exercise.

Besides the point... almost nothing will be achieved by making elsip faster. I sometimes write macros to work on GBs of files and yes, it isn't fast... but if i cared about speed i'd be shelling out to cli tools to do the work anyway.

Makes. No. Sense.

Fork it if you must and leave the rest of us alone.

Reply on news.ycombinator.com