Re: proplib and the jet age

[Marc Balmer <marc%msys.ch@localhost>]

Am 05.01.2013 um 01:25 schrieb David Holland 
<dholland-tech%NetBSD.org@localhost>:

> On Tue, Jan 01, 2013 at 10:04:11AM +0100, Marc Balmer wrote:
>>> The chief question, therefore, is what data model the new stuff should
>>> support. There are at least seven obvious candidates I can think of:
>>> 
>>> [snip]
>> 
>> Let me add another option here: Lua could be used just for that.
> 
> Lua is not itself a data model. It *has* a data model for data
> appearing in Lua programs. One could use that, but as far as I know
> it's an instance of (c).

It evolved from Sol, a language to describe data.

> If you're talking about using Lua syntax as the transfer format, I
> don't see any advantage over e.g. JSON and the disadvantage of being
> much less widely used elsewhere.

Lua has several advantages over JSON as a data transfer format, and be it only 
speed.  "Being much less used" is just FUD.  If we start accepting usage counts 
as arguments pro or con a piece of software then we might as well stop NetBSD 
entirely, it's much less used than windows, e.g....

And, since Lua can very effectively decode JSON, you could even read JSON files 
or data in Lua.  So Lua wins here, I'd say.

In fact Lua is probably much wider used than you thing, ranging from computer 
games (LucasArts, Blizzard, many others), printers (Olivetti), commercial 
software (Adobe Lightroom), computer tomographs etc.

While I don't believe much in usage indexes like TIOBE, they can be 
interesting, too.  At least it mentions Lua. even in the top 20.  But I would 
not take this listing as a valid argument pro or con a language either...

> If you're talking about using the Lua interpreter to receive data by
> executing incoming data as code and dumping out the Lua tables found
> in the interpreter afterwards... in addition to the obvious hazards of
> making things executable that shouldn't be, this is a very expensive
> and ass-backwards way to avoid writing 500 lines of parsing code, and
> I don't see the point.

There is the big advantage of simplicity and using a defined language and 
proven runtime system (which is, as has been mentioned, very fast and much 
tailored to exactly this use case).  You new parsing code would probably 
introduce a new syntax and who knows how many bugs would lurk in it?

So yes, I do see a point in using Lua as a configuration language.  And no, I 
do not mean that everyone should jump this bandwagon, I see Lua as an option 
that is a valid choice for those who want.

We don't have a single configuration parser now either.