lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andre de Leiradella wrote:
[...]
> I don't seem to remember the necessity that brought Lua modules to life.
> Was it to make life easier for the language users? Who are the language
> users?

Yup.

Lua means two things, and it's all too easy to confuse them.

The first Lua is the *language*. This is the tiny core of the system
that's been there for years (long may it not grow).

The second Lua is the *platform*. This is the complete programming
environment based around the Lua language. This consists of the
language, of course, but also the complete set of libraries to actually
get work done; and, most crucially, it also consists of the
specifications and processes in place to allow Lua to be extended
orthogonally.

It sounds like what you're after is the Lua *language*, with very little
*platform*.

The thing is, they're both utterly vital things to have. Back in the Old
Days the platform was really just an afterthought to the language,
without proper modules, and everything was just hacked into the
interpreter on an ad-hoc basis. Writing standalone scripts was a
nightmare! If you tended to work solely in the embedded world, you may
not have noticed this, but trying to deploy an actual Lua *application*
was basically impossible --- there was no workable means of adding all
the necessary functionality to the user's Lua interpreter beyond
shipping a complete customised interpreter.

The New Way really is an improvement. It's made life vastly easier for
desktop people. It's also made life easier for embedded people, because
the module system is useful for them, too --- and if you don't need it,
you can still do things the old way and that still works fine.

(I work in both the embedded and desktop worlds, and in fact I would
like the distinction between the language and the environment to be
widened --- core Lua still has a number of dependency on things like
stdio that some embedded devices don't have, and it would be rather nice
to have a core CPU-only Lua library that had *no* I/O at all, with even
stuff like print, io, and loadfile() abstracted out.)

[...]
> Lua has always been simple and easily embeddable. It still is. But its
> libraries aren't anymore.

Weeelll...

I think you're having problems because you're wanting to have your cake
and eat it, too; you're wanting to use complex modules like luasocket
without having the complexity. That's not going to work, more or less by
definition. If you want to have mixed Lua/C modules, you need the
framework for managing mixed Lua/C modules. (And if you don't, you don't
- --- you can still load C-only modules in precisely the same way that we
used to.)

What you want is a set of custom loaders that provide access to C
modules via direct linkage and Lua modules via embedded chunks of Lua
code. It's not a lot of code, and would give you the ability to
dynamically load modules as needed on your filesystem-less embedded
device in precisely the same way that you would on the desktop. This has
huge implications for testing and debugging; doesn't the idea of being
able to run scripts on the desktop before running 'make' and directly
producing a firmware image for your SoC appeal to you? It does to me!

That said, I *am* surprised that nobody's come up with a harness to make
this stuff easier yet. It should be nearly trivial to write a set of
loaders in C that use a big lookup table to find modules, and almost as
trivial to write a command-line tool (in Lua, naturally) that would
parse a rockspec file and automatically populate said table, complete
with turning the Lua scripts into embedded data. Am I wrong? Does
someone have such a thing? It would be dead handy --- I could have used
it for Wordgrinder.

(In fact, it would be very easy to do with Prime Mover, which supports
dynamically generated code really well. Hmm...)

- --
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│
│ "People who think they know everything really annoy those of us who
│ know we don't." --- Bjarne Stroustrup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKoXaff9E0noFvlzgRApeqAKDK2O9tOI96gewdCrGV0G/pDO5tUACfd/jZ
fyoY+ryWBmVJTq9BSLpiHTc=
=ssXg
-----END PGP SIGNATURE-----