Four paradigms for programming Lua apllications

[Dirk Laurie <dirk.laurie@...>]

You're writing an application in Lua. What are you presenting to the
intended user?

1. A standalone in "pure" Lua. The first line starts with a shebang
just like Python programs. Iteraction with your program is via
a user interface that you control. User-written Lua scripts, if allowed
at all, are tightly sandboxed.

2. A precompiled standalone. You have a C main program, compiled
what you need of the Lua source code of a particular release, which
calls your script. No changes in current Lua can affect you.

3. A module. Your user is also a Lua programmer and your module is
"batteries". Your post-5.2 ideal is to be as unintrusive as possible:
the user should require your module, and if he fails to assign the
result to a name, the only trace of your module is an entry in
package.loaded.

4. A console application. Before 5.3 this was not a popular possibility,
because typing `=` is such a PITA. It will now become one. You invoke
it with `lua53 -l app` to take advantage of Lua's module path, but it is
not really a mere module, it is a full application that may have changed
all of _G and retains only the bare Lua language and REPL. It may
well be running its own little DSL disguised as Lua calls.

And now I'm off to working on my current #4 type project ...