Re: Soft Types System Proposal

[Asger Alstrup <aalstrup@...>]

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