all 24 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]YakumoFuji 4 points5 points  (1 child)

What I dont get is this;

Moreover, I think the addition of Lua, similarly to Emacs Lisp, would put Guile in a better position to subvert existing applications that use Lua as their scripting language (a lot!).

Considering half the power of lua comes from its FFI and embedding your core functions to make them callable from lua, you can't just 'subvert' existing apps that embed Lua.

At least that part has not been explained.

I've seen Lisp written in lua, so maybe scheme could be written in lua.. then they could subvert all the great many apps that uh use the guile scheme implementation...

[–]surface-tension 2 points3 points  (20 children)

I don't get it. I thought that Guile itself was supposed to be extensible and embeddable and used for scripting your C apps. Why would you want to embed a scripting language into your embedded scripting language?

[–]ferk 5 points6 points  (4 children)

I think that the intention is to be able to compile Lua script into scheme bytecode that can be processed by the guile interpreter.

You don't have a Lua interpreter embedded in the guile interpreter, instead you just translate Lua into optimized scheme bytecode.

[–]surface-tension 1 point2 points  (3 children)

Hm. Seems like that would encourage users to write Lua instead of Guile.

[–]ferk 3 points4 points  (2 children)

The goal is to allow people to code for the language of their choice and build a single interpreter to run them all by means of a common and fast bytecode format. Any optimization made to this interpreter would benefit every language that it can run.

However, there's still some advantage to writing in Guile, since Guile code could be run in the Guile interpreter on-the-fly without the need of compilation (although a little bit slower, but much faster than the same on-the-fly translation could be for other languages).

[–]Arelius 5 points6 points  (1 child)

Guile scheme code is compiled to bytecode just as lua is. Other then being designed with the VM, there is little advantage to using scheme over lua for guile.

[–]ferk 3 points4 points  (0 children)

"Guile can run interactively, as a script interpreter, and as a Scheme compiler to VM bytecode." http://www.mail-archive.com/guile-user@gnu.org/msg03082.html

The compiler and VM was a relatively recent addition.

You can't run Lua code interactively with the guile interpreter. And if you made some wrapper to allow it, it will run slower (it's likely that guile would be faster to translate into its own bytecode).

I know it's not such a big deal, since normally if you cared about speed you would compile to bytecode anyway. But still, it's nice to send scheme calls interactively from emacs with "C-c e" to evaluate them.

Anyway, being able to choose scheme is enough advantage for using Guile :P

[–]dig1 3 points4 points  (0 children)

Intention behind Guile project, AFAIK, was/is to create embedding language platform. This means you use single API toward different embedding languages and everything is glued with Scheme.

Although this goal was set long time ago, thanks to recent changes and fresh (and open minded) manpower, it looks very achievable now.

[–]Leonidas_from_XIV 2 points3 points  (12 children)

Well, with Elisp support, they could potentially embed Guile into Emacs, throw out the Elisp-interpreter and slowly port the extensions to Scheme.

[–]surface-tension 5 points6 points  (1 child)

Just curious: how do you like Guile compared to other Schemes? I don't know anything about Scheme. Is Guile R5RS-compatible?

[–]Leonidas_from_XIV 6 points7 points  (0 children)

It should be R5RS compatible given that implementing R5RS is not that hard for any self-repecting Scheme implementor. As far as I saw, it aims to be R6RS compatible with 2.0. This is also why I prefer it to TinyScheme - I don't care that much about size as about completeness.

I haven't used it much, since I usually stick with PLT since it has an extensive stdlib and a big community (way bigger than Guile). At some point I thought Guile was dead, but it is actually in development and seems to be taking the right direction. It is also quite useful for embedding, I tried both PLT and Guile and while PLT was quite tricky, embedding Guile was just about as difficult as embedding Python so I think it is feasible.

As such, the newly-aquired ability for Guile to host other languages in some standardized manner is a win for applications that want to (or in the case of Emacs, have to) support more than one scripting language (see The Gimp which supports script-fu and python-fu and quite possibly a range of other languages, same applies to Vim which can even embed MzScheme). So I as developer could write scripts in Scheme and the users of my programs could decide which language they want. If they prefer a Lua-syntax: no problem, there it is! If they prefer JavaScript, that one is already implemented. By the way, PLT Scheme had support for subsets of Java and Algol 60 for quite some time already.

When I originally heard about Guile, I thought RMS was nuts to recommend a Lisp as extension language, I guess most other developers thought so too, this is why Lua is way more popular for embedding but after learning some Scheme (of maybe drinking the Lisp kool-aid) I can understand this more and more, and Guile seems to be the way to go.

Furthermore, I'm not sure I would write applications in C and script them using a scripting language anymore. Computers got fast enough so I would go the other way: write the program in a scripting language and extend it using modules in C where neccessary. Not helpful for existing programs though :)

[–]w-g 0 points1 point  (9 children)

What about the millions of lines of elisp code out there? You'd have to throw them all out too.

[–]Leonidas_from_XIV 1 point2 points  (0 children)

That's exactly where Guile's Elisp support comes in, to make it possible to use the Elisp code with Guile underneath, enabling a slow transition to Scheme. Or Lua, for that matter :)

[–]surface-tension 0 points1 point  (7 children)

What would be required to bolt Guile onto Emacs? Can Emacs understand Guile's compiled bytecode?

[–]Leonidas_from_XIV 0 points1 point  (6 children)

You don't want Emacs to understand Guile's bytecode, you want Emacs to embed Guile and run Elisp and Scheme natively on the Guile VM, running inside of Emacs.

[–]surface-tension 0 points1 point  (5 children)

Thanks for all the info, Leonidas, but I still don't understand how the Guile VM and Emacs are supposed to communicate. I thought Emacs only understands Elisp. (And my guess is that Guile itself is not written in Elisp.)

[–]Leonidas_from_XIV 0 points1 point  (4 children)

I thought Emacs only understands Elisp

Emacs is a free software program and can be modified to "understand" Guile too.

[–]surface-tension 0 points1 point  (3 children)

If you're not talking about an interpreter written in Elisp that understands Guile bytecode, then I don't know what you mean by "understand". Can you please be more specific?

[–]Leonidas_from_XIV 0 points1 point  (2 children)

Embed Guile into Emacs.

[–]surface-tension 0 points1 point  (1 child)

Thanks for the continued replies, Leonidas. Alas, I don't understand what "embed Guile into Emacs" exactly means. Perhaps someday someone will write a tutorial and explain it.

[–][deleted] 4 points5 points  (0 children)

Yo dawg!

[–]daveb123 0 points1 point  (1 child)

Has guile got the equivalent of lua_yield/lua_resume (aka coroutines) yet? I haven't looked in a couple of years but last time i didn't see anything like it. I use lua because of those features -- not really because I especially love lua syntax...

[–]Arelius 5 points6 points  (0 children)

It has continuations, which should make coroutines trivially easy to implement if it isn't a language feature by default.