lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

You can have any variety, really. Even applications where Lua is both being embedded and extended.

One case would be a web service currently utilizing a custom scripting language. Moving that to use Lua, while keeping the application (the service part) rather intact. Service calls will be able to give code snippets via URL. That would be embedding.

Then again, such code could say "require" and take advantage of any extensions the server has been catered with.

In many scenarios, I would see the main application to be in the "native" programming language. But it rather easily becomes only the frame around the codebase, which will get to be increasingly Lua. Since Lua is such a good tool to get stuff done more conveniently. This happened to Adobe in Lightroom (some 70% Lua). I expect it could happen to the server case, too. By the years.

If you have an existing codebase that works, you might not want to change it all to Lua just for the sake of changing. I hope this answered your wondering a bit.

-asko kirjoitti 6.11.2008 kello 23:01:

Hello! I've been reading and learning about Lua for a bit and have a
question: When is it appropriate to embed Lua, instead of extending it? I ask because for most scripting languages (Perl/python/ruby), the only
real option is to extend the language, by writing a binding to the
target library through the language's FFI (foreign function
interface)... so the entire concept of embedding a language is foreign
to me. The way I see it, it makes more sense for the higher-level
language Lua to be the 'host' language from which you make calls to
foreign libs, than to have the lower-level language (C) be the 'host'
and embedding Lua. I *think* I am missing something cool here, but I
can't really put my finger on it... can anyone give me an example where
embedding Lua was a better option than extending it?