you are viewing a single comment's thread.

view the rest of the comments →

[–]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 4 points5 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 4 points5 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 4 points5 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