Guile Scheme Emacs-Lisp Compatibility Matures 46
In a posting to the Guile developers list
today, it was announced that the Emacs-Lisp
compiler for Guile has matured enough to run actual elisp
programs. The author included a screencast demoing
the new compiler running the Dunnet
dungeon crawler. It is still a bit hackish: you need a load file that fakes a few Emacs side functions. In theory, most batch mode programs that don't do buffer manipulation should now work. After a few previous attempts, things could be on track for GNU Emacs 25 based on Guile.
Re: (Score:3)
I think you mean "(car posts)".
Sonic boom! (Score:2)
Re: (Score:1)
Has anyone embedded Guile? (Score:3)
I've heard of Guile in the past, but I never managed to come across any application that actually uses it. Guile's own project list is rather meek [gnu.org], and whenever people talk about embedding a programming language, the talk appears to always shift to Lua [lua.org]. Does anyone know why no one picks Guile for any task? It would be great if it was possible to hear from anyone who actually gave Guile a try in any project.
Re: (Score:3)
The one application that I am aware of that does make use of Guile is GnuCash and it uses Guile for generating reports.
Re:Has anyone embedded Guile? (Score:4, Informative)
TeXmacs and Lilypond also embed Guile.
Re: (Score:1)
I'd think it's rather logical that the GNU project is dogfooding.
Re: (Score:3, Interesting)
There are many other apps using it, like gnucash.
Having used it before I can tell you that the C API is very well made, and C and scheme can call each other with few limitations. Scheme is an elegant language too.
Lua has three main advantages over guile. It is trivial to package, has a smaller footprint, and works anywhere. Guile only really supports posix and windows.
But the main competitor to guile is not lua, it is python. And the battle is all but lost. The two offer about the same functionality. They c
Re: (Score:2)
Yeah, but then back in 2000, John Tobey released an emacs with perl embedded. The FSF folks promptly talked him out of doing that work. If what they wanted was a large third-party developer base, they could've had it over ten years ago.
Re: (Score:2)
They can easily interface with the outside (unlike Lua) and the C API works similarly, but python wins due to its more traditional syntax and larger developer base.
Wait, what? How do you come to the conclusion that Lua "can't easily interface with the outside"?
[Lua and Python / Guile are very similar in overall form. Lua is much faster, much smaller, easier to embed, and has a better C interface than Python, but Python has more libraries (including many that are included by default) and a larger user-base. Guile I dunno about, it seems to have the bad points of both (large/bloated + not much support or user-base)...]
Re: (Score:1)
I meant that Lua has a limited standard library so a lot of stuff will require C. Guile by contrast has a POSIX system calls interface, networking, an html module, etc... Python has even more stuff. And it is my understanding that Lua is most often used sandboxed, like javascript, rather than to write standalone applications.
Re: (Score:3)
Hmmm, of course such libraries do exist for Lua, it's just that you'll have to download them separately rather than finding them in the tarball that contains the actual interpreter...
The most common use of Lua is as an "embedded" language—app is written in C, but linked with a Lua interpreter which the app calls to do whatever stuff it wants. I don't think actual sandboxing is all that common—it's common, for instance, for "embedded" Lua code to load various external modules/libraries to do st
Re: (Score:1)
That's a popular misconception. The rule of thumb which typically works out well is, Lua is faster for math heavy, low precision operations while python is faster and better for pretty much everything else.
For a lot of games, the interface tends to add this number to that number and compare to intuit some meaning. For that, Lua is in deed pretty fast. For most everything else, python is generally on par or even faster. The more you need a general purpose language, the more appealing and faster python genera
Re: (Score:1)
You are misformed. Lua is much faster than python in pretty much any normal application. [and that's normal Lua—LuaJIT is of course, even faster.]
Python has its strong points, but speed is not one of them.
Re: (Score:2)
Nobody picks guile because in practice it's hard to do anything real with it. Possibly that's changed since the last time I evaluated it, but last time I evaluated it, batteries were most definitely not included.
Re: (Score:1)
Guile 2.0 is a huge improvement over earlier releases. Scheme programs are now compiled for a custom VM with an optimizing compiler (not simply interpreted, and AOT or JIT native compilation are now much more practical goals), and Guile now supports hygienic macros, delimited continuations, Unicode, dynamic FFI, R6RS and more SRFIs, and comes with a new debugger and REPL, SXML, and a Web server, among other new standard modules. There's also a SLIME-like Emacs interface: http://www.nongnu.org/geiser/ [nongnu.org]
It's d
Re: (Score:3, Informative)
Re: (Score:2)
I wouldn't recommend it as a scripting language to other projects, though.
The API is not very good, and the release pace has been glacial.
Re: (Score:3)
Re: (Score:2)
The attitude of many towards lisp/scheme was probably a factor, but I think not the major one. As can be seen by the huge number of Emacs extensions, people can deal with lisp, even if it's not everybody's first choice. [...and note that this is true even with Emacs' somewhat inelegant lisp dialect and lack of many modern features; people will put up with a lot of crap if the reward is immediate...]
The real problem, I think, was that Guile never had a particularly usable or attractive implementation
Re: (Score:3)
GNU Robots [gnu.org] uses Guile, but I don't see it on the list. GNU Robots lets you construct a program for a robot, then you set it loose in a virtual environment. It can use sensors to detect objects, blast baddies, pick up rewards, and move around. You write the program in Scheme, which is loaded by GNU Robots via Guile.
Guile Scheme (Score:1)
Lisp is... (Score:1)
Re:Lisp is... (Score:4, Funny)
But don't let that discourage you too much, lisp might be worth learning in any case.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Glad to see this on Slashdot! (Score:4, Funny)
This is the kind of article I'm always glad to see on Slashdot; emacs is cool, Lisp is cool, an article on something that's genuinely hardcore nerdy is always good to see! With the Linux on 8-bit micro article also posted today it feels like the nerd coefficient is running high today! Good!
Long time in the making (Score:2)
Boy, this has been a long time in the making. It seems to me they were talking about this 10 years ago.
The problem with all the scheme implementations is none of them are up to the task of real world work. You want good C function call integration? Get one variant of scheme. You want to do X windows guis? Get a different one. You want nice UNIX system call interface? Different one again. You want to do cross platform gui work? Good luck with that. Scheme could have gone quite a long way if all their forces
Re: (Score:2)
Check out Racket [racket-lang.org]. It is fast, comes with "batteries included", and even has a fairly feature-complete cross-platform GUI toolkit. It even has its own built-in web server.
Some people claim it's no longer Scheme, though, because Racket lists are immutable.
I tried Guile recently... (Score:3)
...and I like it; surprisingly so. Scheme is off-putting at first (and Andy Wingos blog posts aimed at long-time seasoned users don't help) but once I sat down and really wrote something in it it turns out to be very expressive and readable.
What Guile needs, I think, is better packaging. Make a full-featured package set for the most popular platforms with the libraries you need to do real, fun stuff. Things like the Cairo and SDL library bindings for instance, and UI bindings.
The libraries you want already exist and work well, but installing them by hand is a pain, especially when your aim is to learn the language, not deal with installation issues.
Then add a set of docs to get things rolling. Docs for the libraries (the Cairo bindings have none; you basically use the C version docs.) A few Hello World-ish tutorials to get going with UI, graphics, communication, language bindings and so on, together with a general introduction to Scheme and Guile. Again, I think most of it is out there already, just not assembled and packaed in an accessible way.
It's a really good system; shame to see it so underused.
Why not Common Lisp? (Score:2)
Re: (Score:1)
> Why not Common Lisp?
For three reasons:
1. Political: GNU doesnt have an own high quality Common Lisp implementation so they would have to base Emacs on a non-GNU implementation and ignore their own existing "extension language". Guile ist the best the GNU project has to offer and several other projects are already using it, while no other gnu project uses Common Lisp.
2. Practical: It is easier to implement the whole of elisp in guile and then to swap guile into emacs instead of the current elisp impleme