7 ms·

Goism – Use Go instead of Emacs Lisp inside Emacs

164 points by demiol 9y ago

josteink 9y ago
I agree Emacs Lisp is pretty inferior as far as lisps go, but IMO this seems pretty misguided. Technically impressive, I'm sure, but will it be around for another 30 years? If someone writes a module using this, will I be able to rely on that module keeping on working for the years to come?
- bigdubs 9y ago
  Why wouldn't that be the case? The golang authors have been pretty strong on backwards compatibility so far (even though it is admittedly a young language).
  - kornish 9y ago
    Is josteink talking about Go or Goism? Probably the latter.
- ams6110 9y ago
  I don't think inferiority of language is a strong argument either. JavaScript is pretty inferior as a programming language but that doesn't seem to have affected its popularity much.
  - jchw 9y ago
    I think that's neither here nor there. JavaScript has a lot of strengths that few other languages can claim at this point, thanks to how universal it is. Many people understand it, it can be used to build everything from desktop apps to mobile apps to servers, and it has one of the largest package repositories out there. I'm far from a JS fanboy but I think your point lends credence to the idea of using JS more than it strengthens the use of Emacs Lisp.
    - taeric 9y ago
      I don't actually see the advantages for JavaScript. Seems every other month there is a new way to package it. So, everyone might know how to build with it, but few people know the same way of building. Similarly, the package repository is not exactly inspiring. Similar patterns of many packages doing the same thing. Often not bringing new advantages to the table, so much as revising old weaknesses. Many rooted in choice of language. Which is actually not too complain of JavaScript. I do like it. And I love that people are empowered to try things. Even if they were previously done. I do wish people knew more options, though. Including myself.
      - jchw 9y ago
        Trust me, I get it. I'm not a fan of JS for the exact stated reasons. It's fragmented and full of holes. But the way I see it, JavaScript is like today's BASIC. In a very fragmented computer market, it seemed like BASIC was the one thing that ran common between a lot of home computers in the 80s. While it's not a perfect parallel, it seems with all of the different platforms that are around today it's hard to find a consumer platform that doesn't have a JavaScript interpreter jammed in it, be it an iPhone or a ChromeCast. BASIC wasn't all sunshine and rainbows either, but it was more than enough to help unify a fragmented world. I think JavaScript is very similar in that respect, and when the dust starts to settle on modern JavaScript it will be closer to accomplishing that goal. Whether or not NPM is actually so impressive though, I won't debate. It's useful, but uhh... yeah. The baseline quality is not quite near something like, say, PyPI.
        fiddlerwoaroof 9y ago
        Also javascript is pretty good at creating dsls as far as non-lisps go. The only real mainstream competitors on this space are ruby, scala and, possibly, rust.
        sedachv 9y ago
        That is actually a great comparison and a very strong argument for not using JavaScript. BASIC was big in the 1980s; where is BASIC today? Elisp code from the 1980s still runs or can be trivially ported to Emacs 25. Lisp is not a fad and Lisp never goes away.
- quasilyte 9y ago
  The potential damage can be reduced. There can be a backend that generates Emacs Lisp code. Not necessary optimized or idiomatic, but it could be a good starting point for rewriting. But in general, I agree with you.
fithisux 9y ago
Congratulations, keep up the good work.
jlarocco 9y ago
Another case where it'd be nice to have a "Why are we doing this?" section in the README. If it's just a demo then it's neat. Interesting that it can be done. On the other hand, if it's a real push to get people scripting Emacs with Go, then I don't see the point at all. It's solving a problem people don't really have.
- hk__2 9y ago
  > It's solving a problem people don't really have. Isn’t "I want to script Emacs but I don’t like LISP" a problem to solve?
  - ue_ 9y ago
    A better thing to answer would be why people prefer less powerful languages to the more powerful, and what can be done about it? Framed that way,this seems like an XY problem.
    - jchw 9y ago
      >why people prefer less powerful languages to the more powerful Clearly, power is the only measure one should consider when picking a programming language. And Lisp surely has more power than Go. I'm going to guess 36.1% more power, to be exact. >and what can be done about it We could always start performing eugenics to get rid of them. ... Okay, I apologize for being an ass. But I hope my points aren't lost; the way you're phrasing things makes it feel like you're bitter that anyone would consider using something that's not Lisp.
      - saghm 9y ago
        I think GP's idea was that having a more flexible language is specifically useful for configuring Emacs, not that Lisp is better than Go in every imaginable case.
        jchw 9y ago
        I haven't tried the linked package, but it seems like the idea is that it can be used alongside Lisp. If so I'm not fully understanding how this isn't a reasonable idea. Surely _being able_ to use Go is not a bad thing and not useless?
Tenobrus 9y ago
I haven't taken an incredibly close look at this, but it seems like a pretty bad idea. Elisp is definitely not a great language, and I'd like an alternative as much as the next Emacs user. But I feel pretty strongly that any alternative has to be a Lisp, or very close to one. Code-is-data/data-is-code is very important for the more "config-file" aspects of configuring Emacs. Being able to use and write DSLs to succinctly encode exactly how you want aspects of the editor to behave is a critical strength. I've tried systems that were configurable in Python and other good-but-non-Lisp languages, and it's always much more annoying, because the language is (purposefully) limited w.r.t metaprogramming and possible DSLs. That's a good thing when optimizing for maintainability by others and obviousness, but not so much when optimizing for maximum personal customizability. Go seems like quite possibly the polar opposite of this, as far in the "keep it simple and understandable by literally everyone by cutting out many techniques for metaprograming and code reuse". Which perhaps is the point, but if so it seems like that point misses much of the draw of Emacs? While this is definitely impressive technically, I think Guile Emacs is a much more plausible option.
- quasilyte 9y ago
  I used Emacs Lisp for scripting tasks like code and data generation. It is great to have an ability to evaluate form right inside the spot you want results to be inserted. This kind of code does not require AST manipulations or macro. Also, some of my projects that become bigger than 1000 LoC could benefit from static typing and (subjectively) better tooling. By the way, I think extending Emacs in Racket would be great; just do not have an idea on how to implement that integration smoothly.
  - kkylin 9y ago
    You may already know about Guile-Emacs, but in case not, take a look at https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs . Guile is not Racket, or more precisely Racket is no longer exactly Scheme, but they are closer to each other than to elisp.
  - sedachv 9y ago
    I use elisp for scripting occasionally (very handy when you need to script on some server but the administrator does not want to install a Lisp compiler, and quite usable with the cl- libraries), and the biggest annoyance is that you need to use buffers to do file IO. That is another layer of boilerplate on top of the Lisp file IO facilities, compared to Bourne shell-style scripting.
justinmk 9y ago
Neovim has a go client[1] for nvim's RPC API. Vim doesn't have bytecode to speak of, so of course there's no transpiler step. But it removes the friction of integrating between nvim <-> go, and that is "useful when it's useful". In particular it enabled a new UI[2] to be built in go. [1] https://github.com/neovim/go-client https://github.com/neovim/go-client [2] https://github.com/dzhou121/gonvim https://github.com/dzhou121/gonvim
ww520 9y ago
Is it possible to have a language transpire/compile to elisp?
- quasilyte 9y ago
  It is possible to emit Emacs Lisp instead of bytecode/lapcode. This was the first code generator target actually. Easier to debug, simpler to trust (for the end user) and not that hard to generate. The problem is that it is harder to implement some features of Go in terms of Emacs Lisp without going down to the virtual machine level. Best examples are arbitrary return statements (can be emulated by throw/catch) and goto.
  - ruricolist 9y ago
    Could you implement arbitrary return with cl-block and cl-return-from?
    - quasilyte 9y ago
      It is technically possible, but optimal solution will require more than catch and throw (cl-lib uses them) Simple demonstration: https://pastebin.com/vXp0qPw3 https://pastebin.com/vXp0qPw3 Some S-expressions with `cl-return' can be rewritten to avoid the need of it (by the optimizer); not sure it covers 100% of the cases though.
    - quasilyte 9y ago
      With minor Emacs Lisp compiler patch (addition of %return, %goto and %label intrinsics), it is now possible to output Lisp that is optimal. Possible implementation (about 20 lines of code): https://github.com/Quasilyte/goism/issues/57 https://github.com/Quasilyte/goism/issues/57 Not sure if "defadvice" around "byte-compile-form" is acceptable for all users.
wcummings 9y ago
What happens if I hover over a goism function and hit M-.? Do I get dumped into the go source?
- quasilyte 9y ago
  Currently, no. Hope I get your question right.. Name mangling scheme preserves fully qualified package path. All goism sources live inside GOPATH (1), so nothing stops us from implementing a jump to Go definition. For given `goism-foo/bar.baz` Emacs symbol, Go definition can be found in `GOPATH/src/foo/bar/` package. Exact location can be found by using existing Go tools (simple grep-like solution can work, too). (1) It can change in future; see https://news.ycombinator.com/item?id=13368846 https://news.ycombinator.com/item?id=13368846 and even more relevant: https://github.com/golang/go/issues/17271 https://github.com/golang/go/issues/17271
busterarm 9y ago
The idea of using a language without Map/Reduce/Filter as a substitute for a Lisp, in an editor built around Lisp...seems vaguely antithetical to me.
- flavio81 9y ago
  Antithetical and immoral (immoral as in "violates ethical principles")
- quasilyte 9y ago
  You can call map/reduce/filter from Go code: `xs := lisp.Mapcar(f, ys)`. Mapconcat is already used inside runtime implementation: https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/builtin.go https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/... (Print and Println functions).
  - 43224gg252 9y ago
    Why did you get downvoted for this?
flavio81 9y ago
What a sad idea. Seriosuly, is that hard to learn Emacs Lisp? Even if one is using Go or Rust (etc) at work, any programmer worth his salt should at least already be familiar with Lisp syntax. It is one of the easiest languages to learn!!
- quasilyte 9y ago
  I love Emacs Lisp. Emacs has really good support for it which continues to improve over time. But.. I love more than one language (and more than one Lisp for sure). Will you try to persuade me that I am wrong in that regard?
  - gkya 9y ago
    Emacs only having elispallows me to fix the third party code that I have in my config, and simplifies all the things. Thoemacs already has C too now, there is module support. I guess it could be possible to use Rust via that interface too, and maybe go. But better keep these to a minimum because elisp is one of the things that makes emacs great
dreamcompiler 9y ago
Why?
solidsnack9000 9y ago
Being able to script the editor in something other than Lisp seems good to me (despite the objections of others in this thread). After all, many people are just scripting settings and stuff for themselves. Might as well not make them jump through hoops to do so. I wonder about the implementation strategy -- why compile to Emacs LISP instead of doing a plugin (FFI) or RPC style setup?
ajarmst 9y ago
Dear God, no. No. Please, just give me Guile. Please. We've been so good. So patient. Guile.
testcross 9y ago
How does it compare to something like https://github.com/janestreet/ecaml https://github.com/janestreet/ecaml ?
- quasilyte 9y ago
  I see three main approaches for the tasks projects like ecaml and goism try to solve: 1. Use a plugin system (ecaml) 2. Transcompile to a target language (gosim and emscripten-like platforms) 3. Embed another VM inside Emacs and call its eval There are many differences between these approaches and I am not sure one of them is objectively better as a general solution. For the end users, all of these approaches can deliver good level of integration (they require different sets of tricks to achieve that).
lngnmn 9y ago
...and write all the types (without generics) - no, thank you! Sarcasm aside, Lisp is as much as possible well-suited for the job of text and AST processing, Emacs is one of the Lisp's "killer apps" and the second best "case study" after classic old-school AI code (PAIP).
kmicklas 9y ago
Replacing a 50s language which a 60s language! Amazing!

164 points by demiol 9y ago

I agree Emacs Lisp is pretty inferior as far as lisps go, but IMO this seems pretty misguided. Technically impressive, I'm sure, but will it be around for another 30 years? If someone writes a module using this, will I be able to rely on that module keeping on working for the years to come?

bigdubs 9y ago
Why wouldn't that be the case? The golang authors have been pretty strong on backwards compatibility so far (even though it is admittedly a young language).
- kornish 9y ago
  Is josteink talking about Go or Goism? Probably the latter.
ams6110 9y ago
I don't think inferiority of language is a strong argument either. JavaScript is pretty inferior as a programming language but that doesn't seem to have affected its popularity much.
- jchw 9y ago
  I think that's neither here nor there. JavaScript has a lot of strengths that few other languages can claim at this point, thanks to how universal it is. Many people understand it, it can be used to build everything from desktop apps to mobile apps to servers, and it has one of the largest package repositories out there. I'm far from a JS fanboy but I think your point lends credence to the idea of using JS more than it strengthens the use of Emacs Lisp.
  - taeric 9y ago
    I don't actually see the advantages for JavaScript. Seems every other month there is a new way to package it. So, everyone might know how to build with it, but few people know the same way of building. Similarly, the package repository is not exactly inspiring. Similar patterns of many packages doing the same thing. Often not bringing new advantages to the table, so much as revising old weaknesses. Many rooted in choice of language. Which is actually not too complain of JavaScript. I do like it. And I love that people are empowered to try things. Even if they were previously done. I do wish people knew more options, though. Including myself.
    - jchw 9y ago
      Trust me, I get it. I'm not a fan of JS for the exact stated reasons. It's fragmented and full of holes. But the way I see it, JavaScript is like today's BASIC. In a very fragmented computer market, it seemed like BASIC was the one thing that ran common between a lot of home computers in the 80s. While it's not a perfect parallel, it seems with all of the different platforms that are around today it's hard to find a consumer platform that doesn't have a JavaScript interpreter jammed in it, be it an iPhone or a ChromeCast. BASIC wasn't all sunshine and rainbows either, but it was more than enough to help unify a fragmented world. I think JavaScript is very similar in that respect, and when the dust starts to settle on modern JavaScript it will be closer to accomplishing that goal. Whether or not NPM is actually so impressive though, I won't debate. It's useful, but uhh... yeah. The baseline quality is not quite near something like, say, PyPI.
      - fiddlerwoaroof 9y ago
        Also javascript is pretty good at creating dsls as far as non-lisps go. The only real mainstream competitors on this space are ruby, scala and, possibly, rust.
      - sedachv 9y ago
        That is actually a great comparison and a very strong argument for not using JavaScript. BASIC was big in the 1980s; where is BASIC today? Elisp code from the 1980s still runs or can be trivially ported to Emacs 25. Lisp is not a fad and Lisp never goes away.
quasilyte 9y ago
The potential damage can be reduced. There can be a backend that generates Emacs Lisp code. Not necessary optimized or idiomatic, but it could be a good starting point for rewriting. But in general, I agree with you.

fithisux 9y ago

Congratulations, keep up the good work.

jlarocco 9y ago

Another case where it'd be nice to have a "Why are we doing this?" section in the README. If it's just a demo then it's neat. Interesting that it can be done. On the other hand, if it's a real push to get people scripting Emacs with Go, then I don't see the point at all. It's solving a problem people don't really have.

hk__2 9y ago
> It's solving a problem people don't really have. Isn’t "I want to script Emacs but I don’t like LISP" a problem to solve?
- ue_ 9y ago
  A better thing to answer would be why people prefer less powerful languages to the more powerful, and what can be done about it? Framed that way,this seems like an XY problem.
  - jchw 9y ago
    >why people prefer less powerful languages to the more powerful Clearly, power is the only measure one should consider when picking a programming language. And Lisp surely has more power than Go. I'm going to guess 36.1% more power, to be exact. >and what can be done about it We could always start performing eugenics to get rid of them. ... Okay, I apologize for being an ass. But I hope my points aren't lost; the way you're phrasing things makes it feel like you're bitter that anyone would consider using something that's not Lisp.
    - saghm 9y ago
      I think GP's idea was that having a more flexible language is specifically useful for configuring Emacs, not that Lisp is better than Go in every imaginable case.
      - jchw 9y ago
        I haven't tried the linked package, but it seems like the idea is that it can be used alongside Lisp. If so I'm not fully understanding how this isn't a reasonable idea. Surely _being able_ to use Go is not a bad thing and not useless?

Tenobrus 9y ago

I haven't taken an incredibly close look at this, but it seems like a pretty bad idea. Elisp is definitely not a great language, and I'd like an alternative as much as the next Emacs user. But I feel pretty strongly that any alternative has to be a Lisp, or very close to one. Code-is-data/data-is-code is very important for the more "config-file" aspects of configuring Emacs. Being able to use and write DSLs to succinctly encode exactly how you want aspects of the editor to behave is a critical strength. I've tried systems that were configurable in Python and other good-but-non-Lisp languages, and it's always much more annoying, because the language is (purposefully) limited w.r.t metaprogramming and possible DSLs. That's a good thing when optimizing for maintainability by others and obviousness, but not so much when optimizing for maximum personal customizability. Go seems like quite possibly the polar opposite of this, as far in the "keep it simple and understandable by literally everyone by cutting out many techniques for metaprograming and code reuse". Which perhaps is the point, but if so it seems like that point misses much of the draw of Emacs? While this is definitely impressive technically, I think Guile Emacs is a much more plausible option.

quasilyte 9y ago
I used Emacs Lisp for scripting tasks like code and data generation. It is great to have an ability to evaluate form right inside the spot you want results to be inserted. This kind of code does not require AST manipulations or macro. Also, some of my projects that become bigger than 1000 LoC could benefit from static typing and (subjectively) better tooling. By the way, I think extending Emacs in Racket would be great; just do not have an idea on how to implement that integration smoothly.
- kkylin 9y ago
  You may already know about Guile-Emacs, but in case not, take a look at https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs . Guile is not Racket, or more precisely Racket is no longer exactly Scheme, but they are closer to each other than to elisp.
- sedachv 9y ago
  I use elisp for scripting occasionally (very handy when you need to script on some server but the administrator does not want to install a Lisp compiler, and quite usable with the cl- libraries), and the biggest annoyance is that you need to use buffers to do file IO. That is another layer of boilerplate on top of the Lisp file IO facilities, compared to Bourne shell-style scripting.

justinmk 9y ago

Neovim has a go client[1] for nvim's RPC API. Vim doesn't have bytecode to speak of, so of course there's no transpiler step. But it removes the friction of integrating between nvim <-> go, and that is "useful when it's useful". In particular it enabled a new UI[2] to be built in go. [1] https://github.com/neovim/go-client https://github.com/neovim/go-client [2] https://github.com/dzhou121/gonvim https://github.com/dzhou121/gonvim

ww520 9y ago

Is it possible to have a language transpire/compile to elisp?

quasilyte 9y ago
It is possible to emit Emacs Lisp instead of bytecode/lapcode. This was the first code generator target actually. Easier to debug, simpler to trust (for the end user) and not that hard to generate. The problem is that it is harder to implement some features of Go in terms of Emacs Lisp without going down to the virtual machine level. Best examples are arbitrary return statements (can be emulated by throw/catch) and goto.
- ruricolist 9y ago
  Could you implement arbitrary return with cl-block and cl-return-from?
  - quasilyte 9y ago
    It is technically possible, but optimal solution will require more than catch and throw (cl-lib uses them) Simple demonstration: https://pastebin.com/vXp0qPw3 https://pastebin.com/vXp0qPw3 Some S-expressions with `cl-return' can be rewritten to avoid the need of it (by the optimizer); not sure it covers 100% of the cases though.
  - quasilyte 9y ago
    With minor Emacs Lisp compiler patch (addition of %return, %goto and %label intrinsics), it is now possible to output Lisp that is optimal. Possible implementation (about 20 lines of code): https://github.com/Quasilyte/goism/issues/57 https://github.com/Quasilyte/goism/issues/57 Not sure if "defadvice" around "byte-compile-form" is acceptable for all users.

wcummings 9y ago

What happens if I hover over a goism function and hit M-.? Do I get dumped into the go source?

quasilyte 9y ago
Currently, no. Hope I get your question right.. Name mangling scheme preserves fully qualified package path. All goism sources live inside GOPATH (1), so nothing stops us from implementing a jump to Go definition. For given `goism-foo/bar.baz` Emacs symbol, Go definition can be found in `GOPATH/src/foo/bar/` package. Exact location can be found by using existing Go tools (simple grep-like solution can work, too). (1) It can change in future; see https://news.ycombinator.com/item?id=13368846 https://news.ycombinator.com/item?id=13368846 and even more relevant: https://github.com/golang/go/issues/17271 https://github.com/golang/go/issues/17271

busterarm 9y ago

The idea of using a language without Map/Reduce/Filter as a substitute for a Lisp, in an editor built around Lisp...seems vaguely antithetical to me.

flavio81 9y ago
Antithetical and immoral (immoral as in "violates ethical principles")
quasilyte 9y ago
You can call map/reduce/filter from Go code: `xs := lisp.Mapcar(f, ys)`. Mapconcat is already used inside runtime implementation: https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/builtin.go https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/... (Print and Println functions).
- 43224gg252 9y ago
  Why did you get downvoted for this?

flavio81 9y ago

What a sad idea. Seriosuly, is that hard to learn Emacs Lisp? Even if one is using Go or Rust (etc) at work, any programmer worth his salt should at least already be familiar with Lisp syntax. It is one of the easiest languages to learn!!

quasilyte 9y ago
I love Emacs Lisp. Emacs has really good support for it which continues to improve over time. But.. I love more than one language (and more than one Lisp for sure). Will you try to persuade me that I am wrong in that regard?
- gkya 9y ago
  Emacs only having elispallows me to fix the third party code that I have in my config, and simplifies all the things. Thoemacs already has C too now, there is module support. I guess it could be possible to use Rust via that interface too, and maybe go. But better keep these to a minimum because elisp is one of the things that makes emacs great

dreamcompiler 9y ago

Why?

solidsnack9000 9y ago

Being able to script the editor in something other than Lisp seems good to me (despite the objections of others in this thread). After all, many people are just scripting settings and stuff for themselves. Might as well not make them jump through hoops to do so. I wonder about the implementation strategy -- why compile to Emacs LISP instead of doing a plugin (FFI) or RPC style setup?

ajarmst 9y ago

Dear God, no. No. Please, just give me Guile. Please. We've been so good. So patient. Guile.

testcross 9y ago

How does it compare to something like https://github.com/janestreet/ecaml https://github.com/janestreet/ecaml ?

quasilyte 9y ago
I see three main approaches for the tasks projects like ecaml and goism try to solve: 1. Use a plugin system (ecaml) 2. Transcompile to a target language (gosim and emscripten-like platforms) 3. Embed another VM inside Emacs and call its eval There are many differences between these approaches and I am not sure one of them is objectively better as a general solution. For the end users, all of these approaches can deliver good level of integration (they require different sets of tricks to achieve that).

lngnmn 9y ago

...and write all the types (without generics) - no, thank you! Sarcasm aside, Lisp is as much as possible well-suited for the job of text and AST processing, Emacs is one of the Lisp's "killer apps" and the second best "case study" after classic old-school AI code (PAIP).

kmicklas 9y ago

Replacing a 50s language which a 60s language! Amazing!