Re: Lua in-kernel (lbuf library)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

"Terry Moore" <tmm%mcci.com@localhost> wrote:
> <...>
> 
> But it was really, really difficult for our embedded C programmers to use.
> 
> We found the following areas of constant problem:
> 
> 1) zero origin versus 1-origin arrays were a constant source of bugs,
> particularly when interoperating with C code. 
> 
> 2) the string escape sequences are almost but not completely compatible
> with C. In particular, in C, \123 is interpreted as octal, but in Lua
> \123 is decimal. This was a constant source of trouble.
> 
> 3) the fact that a reference uninitialized variable or missing array
> element returns nil instead of throwing an exception is problematic for
> writing significant code that is intended to be reliable -- errors are
> hidden.
> 
> 4) the Lua APIs are not a platform -- they change from version to version.
> (Working with Lua APIs and trying to track current is like working with
> certain open-source kernels -- you really can't maintain your investment.)
> 
> And so forth. All of these decisions are actually fine, in context of a
> scripting language that's a world unto itself. But as a tool to give C
> programmers, they collectively were a real barrier to adoption.
> 
> To address this, and to make it more palatable to our developers, after
> two years or so of experience (in 2002) MCCI forked the Lua interpreter
> and created a C-like variant (with renamed, stable APIs to address #4, and
> C-like syntax).  There was a paper on this at the Lua conference in 2008:
> http://www.lua.org/wshop08.html#moore
> 
> With that, we've been happily using something based on Lua, and I can
> agree with all the Lua enthusiasts: it's a great tool.  If we weren't an
> entirely C-based company, we would not have bothered with the language
> changes (though we might have created stable APIs with non-clashing
> names).
> 
> I'm not promoting our version as a solution. I am, however, pointing out
> that items #1 and #2 above merit careful consideration before putting Lua
> into a security-critical environment; C programmers won't like reviewing
> the code (and will tend to miss things).

Yet again, this whole story just makes me wonder why AWK has never
evolved to be more powerful language for this kind of purpose (Perl is
not the direction I am talking about).  Certainly, simplicity of AWK
is valued.  However, it does not mean that it should have just stopped
evolving at some point in history.

Even if its functions use 1-origin for arrays, the language itself is
much more natural for the C programmers and the UNIX world.  Personally,
I would love to see more advanced AWK with just-in-time compilation..

-- 
Mindaugas