Re: Proposal: Lua Table Notation + load change

[Coda Highland <chighland@...>]

On Thu, Jun 28, 2012 at 4:22 PM, Julien Duminil
<julien.duminil@ubisoft.com> wrote:
> Hi List,
>
> Here is my two-in-one proposal :
>
> * PROPOSAL 1: Create a JSON-like Lua-compatible format (we can call it LTN for Lua Table Notation or LuT for LuaTable or whatever you want).
>
> This format must be:
> - A subset of the Lua grammar (the Lua-compatible part), so that we don’t need another parser to read those data in a Lua enabled software.
> - Easy to read in another language (the JSON-like part), so that it could be a JSON replacement for data interchange.
> - Bonus: Supported by the official Lua website, to give more visibility to either this data format and Lua.
>
> * PROPOSAL 2: Change the behavior of dofile, load, loadfile, etc. so that if the source only contains a table, the returned chunk returns this table.
>
> Some examples here:
> - example 1:
>        local position = load(“{ x = 5, y = 10 }”)()
> - example 2:
>        -- my_light_module.lua:
>        {
>                var = “some value”,
>                log = function(self, …) print("log: ", ...) end
>        }
>        -- now you can do: local my_mod = require ’my_light_module’
>        -- note that this example has very limited use cases, because log can't access var
> - example 3:
>    local data = dofile 'my_data.lut' -- here is the link between the two proposals :)
>
> Maybe this behavior could also be extended to return the value if the source contains only a boolean, a string or a number.
>
> * Here is a LTN grammar proposal example:
>
>        tableconstructor ::= ‘{’ [fieldlist] ‘}’
>
>        key ::=  false | true | Number | String
>
>        value ::=  key | tableconstructor | nil
>
>        fieldlist ::= field {fieldsep field} [fieldsep]
>
>        field ::= ‘[’ key ‘]’ ‘=’ value | Name ‘=’ value | value
>
>        fieldsep ::= ‘,’ | ‘;’
>
> Maybe tableconstructor should be allowed in key to tease non-Lua users, but it can complicate the internal storage when parsed in some other languages ...
> And in a such format, Number, String and Name must be defined more precisely.
>
> What do you think about this proposal?
>
> Julien
>
> PS: I like the way the JSON grammar is displayed on http://www.json.org/
>

NB: function loadvaluefromstring(s) return loadstring("return "..s)() end

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.)

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 :.

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.

/s/ Adam