Re: Lua as a scripting language in NetBSD

[Marc Balmer <mbalmer%NetBSD.org@localhost>]

Am 17.10.09 11:39, schrieb Marc Balmer:

> I am suggesting to add the language Lua to the NetBSD base system as a
> scripting language for general use and as a scripting language to be
> embedded in applications in the base system.  Please let me explain why
> and what the conseqeunces of such an addition would be.
> 
> Lua is a scripting language with a very small memory footprint that has
> been designed as an embedded (or hosted) language from the ground up. 
> As such, it's integration into software written in e.g. C or C++ is
> straighforward.  Lua is very fast, it is recognized as one of the
> fastest scripting languages.  The language has a clear and simple syntax
> with some very powerful concepts; the libraries (called packages) that
> come with it are themselves reasonable small.  Lua compiles programs to
> a bytecode which is executed by a very small virtual machine.  Lua
> scripts can be precompiled to bytecode for faster load times (but not
> faster execution). The first versions of Lua date back in 1993, so the
> language is stable and mature.
> 
> (The Lua homepage is at http://www.lua.org/, the reference manual can be
> found at http://www.lua.org/manual/5.1/. More information about Lua can
> also be found at http://www.lua.org/about.html)
> 
> Lua is an excellent candidate as a scripting language in base, because
> it is small, fast, and powerful and a user can learn it very quickly. 
> For endusers, having Lua can leverage scripting in NetBSD, e.g. if a
> reasonable interface to e.g. POSIX functionality is provided. (which
> exists with the luaposix package, btw).  For developers of software
> written in C it is a very convenient and efficient means to extend the
> software by a scripting engine.
> 
> Lua would allow us to extend exisiting software in interesting ways,
> DHCP option processing in DHCP clients comes to my mind, or even the
> system installer, sysinst (not to speak of the advantages of keeping
> airport codes up to date using Lua scripts...) I have more ideas, but I
> want to discuss the general case of having Lua in base first, well aware
> that it is a chicken and egg problem:  To use Lua in base, we need it in
> base.  To have Lua in base, we need software that makes use of it...
> 
> Examples of software that uses Lua as the engine for scripting purposes
> are e.g. Adobe Lightroom, World of Warcraft.  It's also used in printers
> manufactured by Océ.  I myself use it in BSD based POS systems.  Look at
> the Lua homepage for more uses.
> 
> Other scripting languages I looked at are Perl and Python (plus
> JavaScript and even Java, which I don't discuss here).  From the
> perspective of efficiency and ease of use, Lua is the best fit:  Perl
> allows you write code nobody can read (loking at some Perl code, I am
> actually amazed that the Perl interpreter understands it...) and
> embedding Perl has some serious problems, too.  Python is a very nice
> language,  but it's strange blocking concept is not liked by everyone. 
> Both Perl and Python use way more memory when embedded, are slower in
> almost all cases, and harder to integrate into existing software.  Plus
> their libraries are bloated, to say the least.
> 
> Having Lua in base of course means that it has to be actively
> maintained, and if it would be added at some time in the future, I am
> volunteering to maintain it by keeping it up to date in -current and
> applying security and stability fixes to -stable branches.
> 
> From private discussions I know that already one or the other developer
> uses Lua and at least a handful of people already told me that they
> could make good use of Lua in base, and so could I.  Please note that
> Lua is in pkgsrc, if you want to try it out.
> 
> So I am opening the discussion about Lua's addition to the base system.

I just imported Lua to NetBSD-current, a little more than a year after I
first came up with the idea.

I whish to thank everyone for their feedback, ideas, and suggestions.
Let the moonshine in ;)

- Marc Balmer