RE : Proposal: Lua Table Notation + load change

[Julien Duminil <julien.duminil@...>]

>That said, your two proposals actually run counter to each other,
>although it's a little subtle.

>One of the things about JSON is that you should never load JSON using
>Javascript's eval() (or Python's equivalent, since JSON is also a
>subset of Python) because that permits arbitrary code execution. Very
>bad idea. Instead, you should parse it and generate a data structure
>from the parsing operation rather than executing code. (Note:
>Sandboxing the evaluation doesn't work on its own because someone
>could pass in "{ x = (function() while(true) do print 'I am a denial
>of service attack' end end)() }"; you have to analyze the syntax tree
>to catch any sort of control flow constructs and prohibit them.)

Good point, I don't have this problem because I mainly use trusted data (I just use sandboxing sometimes to cacth some function results).
However you can have trusted data (and run it with Lua) and want to share it with other people (they will use a specific parser, in Lua or another language, if they don't trust those data).

>In light of this, it would be inappropriate to actually do the second
>proposal as-written if you want the first proposal to take off. It
>would be more appropriate to have a separate parser (perhaps forked
>from the Lua parser) that does the job. And at that point, proposal 1
>stops making sense because you might as well just use JSON at that
>point because the only substantial difference for the "safe" subset is
>that Lua uses = where JSON would use :.

The main difference I see between JSON and the Lua subset is the JSON object/array versus the Lua table constructor.
I think it's one of the Lua thing poeple like: a Lua table can be a JSON object, a JSON array or both.

(It can also be a way to make people that don't use Lua to discover a part of the Lua syntax ...)

>Lua's suitability for use as a config file language draws from the
>fact that config files are supposed to be trusted code -- the same
>user that controls the software (that is, the server administrator)
>also controls the config file. If you are instead looking at data
>exchange with an untrusted source, that benefit is no longer available
>to you.

It's up to you to decide if you trust your data versus you trust your parsing code to safely handle those data ... :)