Re: Lua as a scripting language in NetBSD

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Oct 18, 2009 at 05:18:31PM -0400, Matthew Mondor wrote:
> On Sun, 18 Oct 2009 20:11:36 +0200
> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> 
> > Actually, with the proper backend code e.g. to implement table matching
> > in C, it might be as fast as PF/ipfilter, if not faster -- thanks to JIT
> > support.
> 
> I admit liking better C and lisp style syntax to algol/pascal-style one
> and have used SpiderMonkey to embed JS into some applications, but have
> no personal experience with Lua embedding.  However when reading about
> Lua it really looks like JS with another syntax.

There are some similarities, but Lua has a much smaller and saner
language core than JavaScript.

> Is the Lua runtime (and stack requirements) really low enough for use
> in the kernel?

Basic VM heap consumption after start up should be somewhere in the area
of 20KB for a standard environment. As side effect of coroutine support,
the stack usage itself is minimal, but I don't have numbers for that.

> As for the mentionned JIT, wouldn't that be MD?  I just read that LLVM is
> a possible Lua target, but then will LLVM also be a requirement?  If it
> refers to LuaJIT instead, is that project already portable and stable
> enough?

Yes, the JIT engine is MD code. You mentioned the main options. The main
point for me is not so much the stability and portability of a specific
JIT implementation, but that it is proven to be a feasible project and
to know the limitations. 

> An initial concern of mine, when thinking of a new general-purpose
> interpreted language in the base system, would be an eventual flood of
> non/semi-technical hackers bloating the base system with scripts and
> affecting the general NetBSD performance/footprint in a few year's
> time.  That might fortunately not happen considering the NetBSD
> development model and the fact that performance-critical parts are
> already implemented in C.  :)

One reason for a embeddable scripting language is to be able to more
easily glue components together. The use e.g. in WoW has shown that Lua
can fill that role. I also thing that it works well as standalone
scripting language for non-trivial tasks. Dealing with more complicated
data structures like two dimensional lists in difficult in awk at times
and next to impossible in sh. Even more important, it is not feasible to
prototype new code in shell or awk and later port it to C, so lowering
the entrance barrier in this regard is not a bad thing. Identifying
performance critical parts always works better when using actual code :)

Joerg