Home

What's in store for the most widely used language by discerning hackers?

Or, in other words, what's the future of Emacs Lisp (and unavoidable HN discussion).

The original message contains some interesting tidbits. I am not sure how the discussion on emacs-devel will develop. But speculating about things such as Guile elisp is, of course, our bailiwick.

By Ehud Lamm at 2014-09-17 05:14 | General | other blogs | 24615 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What a horrible swamp of wifty thinking

There is hopeless confusion between switching Emacs to another Elisp engine (which can handle more than just Elisp) and switching Elisp development to another language (Scheme, Common Lisp, JavaScript, Lua, or Whatnot). Emoting ranges from "JavaScript in Emacs will bring in zillions of JavaScript developers!" to "Ewww, doing Emacs in JavaScript will be so ugly, JavaScript programmers will be revolted!" to "We dare not fractionate the huge and monolithic Emacs community!"

I've played with Guile's Elisp implementation a little bit. Meta-warning: the first form you evaluate will spew a lot of warnings, which you can ignore.

    —John Cowan, "ex" troglodyte

By johnwcowan at Wed, 2014-09-17 14:31 | login or register to post comments

legacy Elisp files

One thing on the (very rambly) thread that stuck out to me is the insistence on bringing all existing Elisp forward.

I believe that is not really a requirement. There are certain core things that everyone uses that just need to be built in. Text editing, syntax highlighting, and VCS integration spring to mind. On the other hand, vast heaps of existing Elisp are relatively niche. Web and Usenet support spring to mind.

Above all, though, how much maintenance does *any* flavor of Emacs really get? It's all just talk until someone steps forward to do it. Awkwardly, the people who would be good at it can also make a good living in industry, so they'd be passing up a lot of money in order to hack on a text editor.

By lexspoon at Wed, 2014-09-17 15:57 | login or register to post comments

please start over

But speculating about things such as Guile elisp is, of course, our bailiwick.

I'll bite.

GNU Emacs is a mostly coherent, well-conceived design. Choices in Emacs Lisp's design and in the core editor design are deeply intertwingled. Retrofits to any other language will be necessarily screwball, starting with basic questions like what is nil, what represents false, what is a character, what is a global variable, and on and on. And none of those language compatibility questions add anything at all to Emacs' usefulness as an editor! They only make it more complicated to think about.

And if you try to force in two languages that themselves have all kinds of nebishy compatibility issues (what is an object in one environment vs. the other? a module? a truth value? a list? and on and on).... what's the point, really?

And I say these things as the original point-man for Guile-as-universal-VM (a bad idea, in retrospect, and one I wasn't really enthusiastic about at the time).

I think Emacs developers have discovered some hard limits on GNU Emacs realistic evolution towards being an extensible word processor, web browser, and so forth.

If I could influence the Emacs developer culture it would be to encourage an attitude that Emacs is like a beautiful vintage car or airplane or some other useful machine. That it wants restoration, polish, sneaky non-retro touches to keep it safe and useful in modern contexts, and functional evolution that is very respectful of "how Emacs developers thought about Emacs in the early days".

Some developers who have a deep appreciation of why Emacs turned out to be quite elegant, empirically speaking, and a deep appreciation for some language (say, R5RS scheme with tasteful extensions) would do better, I think, to start from scratch. Perhaps with a different goal such as to build a tiny, extensible, self-documenting multi-media word processor (that sure, can support an extension package that turns it into a nice key-stroke-similar text editor).

I hope any such developers would carefully think about the details (good and bad) of Emacs' methods of input event processing, it's command loop structure, it's features for self-documentation, it's management of "C objects" (such as buffers) vs lisp objects, it's separation between buffers and windows, and its old-skool-lisp style of emphasizing use of a small number of very generic data types rather than a thicket of object types.

By Thomas Lord at Wed, 2014-09-17 17:30 | login or register to post comments

a different goal such as to

a different goal such as to build a tiny, extensible, self-documenting multi-media word processor

Or, with respect to modern developments, a tiny, extensible wiki. :)

(Or maybe hypercard.)

I agree with what you're saying here.

By dmbarbour at Wed, 2014-09-17 18:36 | login or register to post comments

Those are many different

Those are many different things, which mirrors Emacs greatest strength (it can do anything) and weakness (it can do anything).

By Sean McDirmid at Thu, 2014-09-18 04:37 | login or register to post comments

hear hear

so where can / will / might you blog about your opinion about all of these? i would love to learn.

By raould at Wed, 2014-09-17 20:34 | login or register to post comments

Scheme and Elisp inter-operation

Scheme and Elisp inter-operation works surprisingly well, despite them being such different Lisps. The one obvious wart is how nil, #false, and () are being handled, but I think even that will not cause issues in practice. Details are at EmacsWiki and emacs-devel.

What amazed me most was the realization that, conceptually, hygienic macros can work not only across modules in a language, but even across similar languages! As long as you're in a language that has the concepts of expressions, identifiers, and lexical scope, you're *mostly* set:

Supporting hygiene in a language with a module system means you probably use an intermediate language (IL) that can express "raw references" to bindings from given modules. So, expressions that are input to your macro from lang X get translated to an IL snippet with the correct raw references, depending on what modules were visible at the call-site of the macro; and the body of the macro, which is in lang Y, also gets translated to an IL snippet with the correct raw references depending on the modules visible at the definition-site of the macro. Then both these IL snippets get pieced together. The snippets have their individual lexical scopes too which don't mix together, as expected with hygiene.

Your IL can probably express lexical bindings too, so if you get an identifier input to your macro from lang X, you can use that with the generic lexical binding construct of lang Y (which your macro body is written in), which just translates to a generic lexical binding in the IL, and it just works as expected, making other input expressions to your macro in lang X see that lexical binding for the identifier, even though the binding was established via lang Y's lexical binder. So macros that take identifiers and a body, and let-bind the given identifiers to something for the given body, will work fine.

(In the case of Elisp, there's conceptually two modules: the function namespace and the variable namespace. When a symbol is being compiled, it results in a raw reference to a binding in either one of those modules, depending on the usual rule that determines whether a symbol stands for a function or variable name.)

Problems remain if your macro actually relies on s-expression structure of expressions, and you want to use the macro in a language that doesn't have that. E.g. (syntax-rules ((my-let x y) (let x y))) would not be usable from JavaScript because it has no syntax equivalent to ((var1 val1) (var2 val2) ...) to be used for x. Similarly, you could pattern-match on a vector literal, which is problematic for JS where [foo, bar] is like `#(,foo ,bar) in Scheme, though it should be fine for Elisp where [foo bar] is really like #(foo bar) i.e. foo and bar aren't evaluated.

By Taylan Ulrich Bayırlı-... at Wed, 2014-09-17 21:51 | login or register to post comments