On human-readability

[Jakob Voß]

If human-readability is no primary design goal, why don't you just use luabins with the "too binary" part replaced by character sequences, base64 etc.? To me luatexts looks like just another layer of complexity without enough benefit to adopt in in other projects. A human-readable data serialization format of Lua data would be of more benefit. You wrote:

• JSON — not Lua-aware (can't encode table-as-key and other fancy values)
• Lua code — needs sandboxing, slower load times

Right, so why not either extending JSON or limiting Lua syntax? JSON is so successful because it looks familiar to users of JavaScript. The same could apply to luatexts: LuaObjectNotation could be a safe subset of Lua syntax to serialize Lua data. Here is a possible subset of Lua syntax:

Exp ::=  nil | false | true | Number | String | Table
Table ::= `{´ [Fieldlist] `}´
Fieldlist ::= Field {Fieldsep Field} [Fieldsep]
Field ::= `[´ Exp `]´ `=´ Exp | Name `=´ Exp | Exp
Fieldsep ::= `,´ | `;´

I also bet that a subset of YAML can encode what is intended by luatexts. If human-readability is no goal, you could also reuse another serialization language such as If ASN.1, XDR, SDXF, Hessian, Thrift, Protocol Buffers, Etch, MGraph, or BSON. The adoption of luatexts will surely benefit from building on top of an existing language that can be restricted or extended! Having said that, I still appreciate your work :-)

[Alexander Gladysh]

Thank you for feedback!

Human-readability is a design goal (it is even in a description of the library). Human-friendliness is not.

• Luabins: not human-readable, not human-friendly. You can not realize what is going on without special tools (e.g. hex dump). Writing format by hand sucks big time.
• Luatexts: human-readable, not human-friendly. Can realize what is going on by reading data dumps without special tools, but it requires some thought. Writing format by hand still relatively hard, but quite doable.
• JSON: human-readable, human-friendly. Can realize what is going on from the first glance (well, more or less, at least if source is formatted well). Can easily write format by hand — as well as Lua table constructors.

About extending JSON or limiting Lua syntax:

It will be not extending JSON, it would be butchering it — it is not that similar to Lua tables.

And, with both JSON and Lua (even limited) there is a problem — to read them you need heavy-weight parsers (relatively to what luatexts parser does). This means that you have to pay dearly for overhead of data being human-friendly, even in the cases when data is almost never read by the human. (If human regularly reads the data and you not extremely pressed by the speed concerns, you probably should not use luatexts — that is what readme explicitly says.)

I did not profile luatexts (yet), but not-too-dissimilar luabins is seven times faster than Lua's loadstring. (If you're not sure that data serialization is a performance bottleneck in your code, then you probably should stick with JSON.)

...And all this goes without mentioning the cost for writing (or modifying!) the actual parser and making it tamper-proof. luatexts, as well as luabins is intended to be used on untrusted data; I will not give any guarantees (as per license text :-) ), but a large part of test suites of both libraries dedicated to testing that aspect of the libraries (albeit in a somewhat ad-hoc way).

So, as you can see, luatexts is not intended a JSON-killer. It is a niche product to satisfy rather specialized needs. It is also a very young product (contrary to more-or-less mature luabins) — and somewhat experimental.

While I will be very happy to see it adopted outside of my development environment, I have not yet decided if I want to actually somehow push adoption of luatexts.

[Jakob Voß]

Ok, so luatexts has a very specific application and performance is the main goal. I only would have designed it different, but my main interest is your project agladysh/browser-lua anyway. Unfortunately there is no bug-free browser-based Lua engine (parsing and executing without additional plugins or server components) yet.