RE: Lua in-kernel (lbuf library)

["Terry Moore" <tmm%mcci.com@localhost>]

HI,

I'm replying to a message that was on tech-userlevel@.  I'm not sure why a
discussion of in-kernel Lua was on tech-userlevel@. I see that other related
messages were on tech-kern@, so I'm posting my reply there.

My company has quite a bit of experience using Lua as a scripting language
-- since 2000.  Lua has many advantages and I like it very much. 

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

Best regards,
--Terry

> -----Original Message-----
> From: tech-userlevel-owner%NetBSD.org@localhost [mailto:tech-userlevel-
> owner%NetBSD.org@localhost] On Behalf Of Mouse
> Sent: Wednesday, October 16, 2013 13:18
> To: tech-userlevel%NetBSD.org@localhost
> Subject: Re: Lua in-kernel (lbuf library)
> 
> >> [...0-origin vs 1-origin arrays...]
> > It is hard to tell what is the least astonishing here.
> 
> Well, least astonishing to whom, is really the question, it seems to
> me.  Certainly I, as a C coder with no Lua experience, would find
> 0-origin arrays less astonishing.  Someone with the converse experience
> would presumably have the opposite reaction.
> 
> > You propose Lua as a language embedded into C rather than separate
> > one.  I'd say that Lua designers made wrong decision here.
> 
> Only if you think of Lua as being designed for embedding in C.  It's
> just as coherent to think of the mistake as being trying to wed a
> language with 1-origin arrays with a language with 0-origin arrays.
> 
> /~\ The ASCII                           Mouse
> \ / Ribbon Campaign
>  X  Against HTML              mouse%rodents-montreal.org@localhost
> / \ Email!         7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B