lua-users home
lua-l archive

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


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