Objective Lua
cowlark.com
cowlark.com
Seriously, Lua is a fine language, and doesn't need this objective-crap thrown in top of it. How to make a simple thing, more complicated. Just b/c you can, doesn't mean you should.
* With a class-based system, you first write an abstract version of what you need, then create instances. With prototypes, you just create the instance, and if generalizing is worth doing (it often isn't!), you can spawn new objects based off of it. I wonder if classes themselves encourage over-abstraction. Of course, you have to use prototypes idiomatically, or they just seem like weird classes. (This is also orthogonal to static analysis.)
To really take advantage of static typing, you would probably need to add support for it to the Lua VM. I don't know of any languages as lightweight as Lua with good static type systems, though - and I agree that an ML-like language as lightweight and clean as Lua could be really nice.
Understandable, but not entirely correct. See StrongTalk. You can have the static typing be in the parser/compiler frontend only. The programmer can get feedback about type metadata, and can use it in refactoring and ensuring program correctness. The VM has to know bupkus about that stuff. In particular Lua's VM is good enough that in most cases it's not needed for performance reasons.
This makes the typing system somewhat circumventable. But the type system is usually circumventable even in a traditional static typed language. At some point, you have to count on programmers not doing stupid things.
On the other side of the coin, such type systems are optional. Which means that you can have less typing for prototyping and rapid development, and more for mature code going into production and maintenance.
I wrote my own library to implement OO concepts in pure Lua 5.1 several years ago; the code and details are still available at http://lua-users.org/wiki/YetAnotherClassImplementation.
Actually, there is a module system (http://www.lua.org/manual/5.1/manual.html#5.3), built on the environment manipulation methods. It was added to the language with 5.1, and seems a bit less mature than the rest of the language, but it's there. It's similar to Erlang's module system, except instead of listing exports at the top, anything not flagged as local is exported.