Re: Using Lua for config files

[Robert Virding <robert.virding@...>]

I think the answer to this question very much depends for whom the application and config files are intended.

If they are meant for savvy Lua users then it is probably ok to allow straight Lua in the config files. You can hope that the users know what they are doing, although you can never be sure.

However, if the application is a package for anyone then the config file must both have a very strict syntax and handling of its contents. Being allowed to enter straight Lua, even if it looks good and is run in a sandbox, would give the non-Lua user way too many ways of getting into trouble. You would need to either write a specialised parser or, if Lua syntax is used directly, check the input.

Is there any standard Lua parser which generates its parse tree ass a Lua data structure?

Robert

----- Original Message -----
> From: "steve donovan" <steve.j.donovan@gmail.com>
> To: "Lua mailing list" <lua-l@lists.lua.org>
> Sent: Saturday, 21 December, 2013 9:01:30 AM
> Subject: Re: Using Lua for config files
> 
> On Fri, Dec 20, 2013 at 6:44 PM, Andrew Starks <andrew.starks@trms.com>
> wrote:
> > I have had this discussion with people at work. They're concerned
> > about what will happen when our users will have access to our
> > "internals". "Tech support is hard enough now. What happens when we're
> > debugging their scripts?"
> 
> It's a valid concern. One point is that one does not willy-nilly
> expose 'internals' to a scripter but a carefully constructed domain
> model for the problems that interest them (the DSL approach). The
> support burden is lessened by ensuring that the scripting interface
> returns useful error messages and can also produce diagnostic logs for
> the support team.  Oh, and documentation ;)
> 
> So it is extra work but the pay-off is a lot of extra flexibility for
> those who are sufficiently curious to learn to extend the system (many
> users would just need a well-defined configuration subset)
> 
> (Totally agree that the best state to approach problems is 'slightly
> stoopid', aka 'beginner's mind'. )
> 
> steve d.
> 
>