Lua: Yet another scripting language?

At various times I have dabbled in a variety of programming languages, from Fortran on. When I started to write programs for computer music I settled on C; eventually, when the benefits of encapsulation became compelling, I moved to C++. I sometimes used Python for quick-and-dirty manipulation of data, notably in my brainwave sonification piece. All of this was done at the command line, since my programs generally didn't have graphical user interfaces. I occasionally used Tk/Tcl for graphics.

Quite recently I moved to the Macintosh OS X platform, for reasons discussed here. I am grappling with Cocoa for constructing user interfaces and handling graphics, and this has meant dealing with Objective-C. After some hesitation I started using the hybrid Objective-C++, which is a weird mixture, but does work. So I have been simultaneously trying to learn about user interfaces in general, learn about Cocoa, and learn about Objective-C++.

Why Lua?

Recently I have become aware of Lua, though it has been around for a while. Why should I care about another scripting language, when I have already made some use of Python, and when I am already dealing with too many new things? The answer is that it seems Lua will solve a specific problem, namely how to read and write configuration files.

In the past I have spent some effort writing routines to read in and parse configuration files. I am now experimenting with using Lua instead, using as a test bed a small program I am writing that generates images. The program has about a dozen parameters that control the image, and as the program develops there may be more. Although the program does have a GUI, there are too many parameters to set conveniently through the GUI. Also, I would like to be able to recreate an image just by loading a configuration file via the GUI.

The biggest claimed advantage of Lua is that it is very easy to embed. I agree: it is easy to add the whole of the Lua source into a project, if I don't want to make any assumptions about libraries. Getting the whole thing to work was no harder than writing a simple parser, and now I know how to do it, so it will be even easier next time.

Another advantage, as a configuration file handler, is unusual flexibility of file format. The procedure for reading in a configuration file is to fire up a Lua interpreter, run the file as a Lua script, and then read into C/C++ the values of Lua global variables set by the script. The script could just consist of statements like

max_life_value = 5

but it can also contain arithmetic expressions, conditionals, loops, and of course comments. All that matters is the values of the global variables of interest after the script has been run.

Two other claimed advantages are small size (the executable isn't bloated too much by adding Lua) and fast running for an interpreted language. Neither has been an issue for me. Finally, Lua is free in every sense (as of course is Python).

More extensive use of Lua

It seems that in the game industry Lua has been used for things like level design, so that a game level can be specified as a Lua script. Further, it is easy to write additional functions for Lua in C/C++, and these additional functions can enable Lua to reach into the C++ part of the program. (I tried a small example.) Following this path would mean a different use of Lua: instead of firing up an interpreter when I need to read in a file and then dismissing it, it would be necessary to keep one interpreter around for the whole program, and a fair amount of the program state would reside in Lua. At present I have no plans to do this.

Alternatives

The game industry discussion mentioned XML and also Python. For small jobs Lua seems to be easier. In the past I thought briefly about embedding Python, but it appeared to be complicated, and I didn't pursue it. Maybe I just didn't have a clear description of what to do. For Lua, instructions are here.

Conclusion

My experiment with Lua was a success, so I will go on using it for configuration files and the like. This means I will routinely be dealing with three languages in a single program: C++, Objective C and Lua. Since I only use fairly basic parts of each of these languages, I think this is manageable.