 |
lua-l archive |
|
|
||
|
Gunnar Zötl wrote:
It is fairly simple as long as you leave tables out of it.
[Fine examples listing how complicated things become if we need to exhaustively type check userdata, overloaded operators and functions. Normal tables and functions without overloading are simple to handle, I hope you agree. ]
I think an 'official' type checking program should be reasonably complete at least for the builtin types. But this makes for quite a complex beast, which will inflate the compiler by quite a few bytes.
I agree that it is not easy to make an exhaustive type checker for Lua that covers everything in the language. Doing that is a research project. For that, I think the best would probably be to try to define the semantics of Lua more formally, and based on a formal description, try to design a type system that captures the essence.
If you were to do this, I agree that it would make sense to do this as a stand-alone tool, since it's a research project. But the very significant disadvantage of a stand-alone tool is the same as what you see with lualint and luaparse which exist today: They only handle a small class of problems, they are not closs platform tools, and they grow obsolete as the language develops, since they are not maintained by the main Lua authors.
So, I believe perfect is the enemy of good. A simple type checking pass handling the basic types, including tables and functions without overloading, is easy to implement and will not bloat the compiler more than a few k. And most importantly, having this in the core Lua distribution would make it really useful for many, many users. The main complaint I get from my programmers is that they really miss type checking. They are so tired of hunting down simple typing errors which can be caught with a very simple type check. I keep telling them to use lualint and luaparse, but they are not convinced, and I can agree with that.
Basically, my reasoning is that the simple type check solution would cover 90% of the demands at a very low cost. In other words, the gain/cost ratio is excellent for the simple type checker.
When you go for the complete thing, the gain/cost ratio is much less convincing, and the nay-sayers that are against type checking will have a point in saying that it might bloat the compiler for little gain (unless someone sufficiently smart could design a very small, sufficient type system.)
Regards, Asger Ottar Alstrup