Re: Proposal: Lua Table Notation + load change

[Marc Balmer <marc@...>]

Am 28.06.2012 um 23:22 schrieb Julien Duminil <julien.duminil@ubisoft.com>:

> 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?

Frankly, not much.  Just because JSON is your hip-of-the-day notation, it should not make it into the language proper.  There are enough JSON libraries around if you want to deal with that format.

> 
> Julien
> 
> PS: I like the way the JSON grammar is displayed on http://www.json.org/
>