Although I'm late to the party, I'm surprised by only 4 mentions of "Lua" in all of comments. At its basis, a valid Lua file can consist of one table. Then the

Although I'm late to the party, I'm surprised by only 4 mentions of "Lua" in all of comments. At its basis, a valid Lua file can consist of one table. Then the data description will be very similar to how people operate with JSON files. At any point the user is able to write code or use other standard library functions... which is pretty limited, but at the same time it's easy to sandbox plain Lua away from "dangerous" functions such as os.exec or the debug library. There are only a few caveats: - Lua uses a 64-bit IEEE float format with some truncated precision - The standard interpreter doesn't handle very huge tables for parsing - Treating .lua as code, not data, you'd likely prepend "return " to your table to just receive the table object from the config file - Unkeyed arrays start from 1, though storing at index 0 is possible - Cascading of data definitions is possible, like fall-through from one semi-filled table to the default table. Use the __index metamethod Personally I find Lua's table syntax vastly more readable than JSON. Although the language naturally has comments, the parser ignores them, if that's something you want. But the same workaround works: just store the comment in some keyname_comment value. Apart from sandboxing you'd only need to limit the script execution time to stop attempts like "while true; end" PS: Lua started as a configuration language. Wiki: > Lua's predecessors were the data-description/configuration languages SOL (Simple Object Language) and DEL (data-entry language).