Re: compile-time globals

[Fabien <fleutot+lua@...>]

Adding static type-checking to a language not designed for it is bound to failure; the best one can do is type a toy subset of the core language, and no usable subset of the standard libs. And anyway, if you look at soundly typed languages, whenever they add a feature, it translate into significant bloat of the type system: it seems extremely hard to escape the current local optima of compile-time detected bugs vs. unproductively tedious bookkeeping (and I'm talking about well designed type systems such as ML's, not Java-like crap).

The current trend, to address that, is to shift more bug detection from static analysis to better testing; but I'd bet that on the long term, lint-like tools, which don't pretend to be exhaustive/sound and therefore can't be called type systems, but can "take risks" and use heuristics, are going to largely supersede traditional type-checking. And I believe the first significant successes are going to happen on well designed dynamic languages :) Actually, it might be argued that some common lisp compilers are almost have such heuristic type-checkers for optimization.

As for type-checking in Lua, to get anything useful, you need quite advanced stuffs, such as table structures. There's a relevant sample in metalua: it supports arbitrarily complex checkings, including parametric and dependent types, but is only offered at runtime: basically, it adds checking code at function beginning for parameters, return statements for function results, and variable declarations / assignments, and can be switched off with a single directive. Functionally it's closer to Eiffel's design-by-contract, but it does its jobs quite well, especially in combination with a bit of testing.

http://metalua.blogspot.com/2007/04/type-checking-reloaded.html

-- Fabien.