Re: Lua as a scripting language in NetBSD

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

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.

Is the Lua runtime (and stack requirements) really low enough for use
in the kernel?  If so that is pretty impressive.  Does anyone have a
rough estimate of the required heap and stack?  Could the kernel also
cope with the fact that the language supports floating point operations
natively, if it was to even be used in the kernel for user scripts?  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?

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

Yet if this was to happen, a language which can compile to predictable
and efficient C might also be good to have (there are a few languages
which are high-level enough, allowing dynamic typing, GC and avoiding
common buffer overflows, yet designed to be efficiently compilable).
Unfortunately, few such languages (and free implementations) exist,
(i.e. CL does but is huge and even ECL has a fairly large memory
footprint, and apparently many people flee at the sight of a few
parens :)  And indeed we really don't want to create/maintain our own
language.  This still doesn't suit the case where a light interpreter
and configuration file reader is what's really needed.

If Lua was in base, was easy to maintain, small and fast enough, and
used where it makes sense, I think it could be a good addition.  If it
can even serve to eventually replace a few components which were
written in sh or awk or C for lack of a better alternative, but for
which those languages hardly suited, it'd even result in a cleaner code
base in the long run (aside from the syntax which I find a bit odd with
all those trailing "end" :).

I've not looked at Lua's "serialization" features much, but if it's
expressive enough, it even might improve the quality of some future
configuration files for which XML or cap_mkdb/getcap would have been
the likely, but non-ideal candidates (i.e. JS has JSON which is not too
far from S-Expressions and is elegant to work with for both humans and
software).  Does Lua have an equivalent?  Of course in the cap_mkdb
case where a very efficient resulting database is wanted, it'd still be
possible to have an alternative configuration format and tool to create
the same internal representation (not that we need a turing complete
language for this, though)...
-- 
Matt