On 4/20/07, Thomas Lauer <thomas.lauer@virgin.net> wrote:
Philippe Lhoste <PhiLho@GMX.net> wrote:
> Or, perhaps, to have a lint for Lua (Lualint? Luint? Luaint? Lintua?
> Lintlua?), to avoid clutering regular lexer with such stuff.
A lint4lua (to throw in yet another moniker) or even an extended luac
(with a few checking and warning options) might give us the best of both
worlds: the fast and uncluttered compiler on the one hand and a more
thorough AST-like offline check of the sources on the other.
I briefly looked into the Yueliang sources (definitely a promising
start) but I just don't have the time right now to do something with
them. Time's always of the essence:-)
Metalua would be a good base for this: it has mechanisms for high-level representation/parsing/transformation of sources. Beyond the compile-time program transformation features it currently focuses on, code analysis and refactoring are in its middle-term scope.
The only fundamental tool missing in the current version is reliable line-number/AST-fragment association. It's being worked on: it makes error reporting not very friendly, which currently is the least enjoyable part of the Metalua programming experience. Most of the underlying mechanisms are in place in metalua
0.3 (the "transformers" field in parsers allow to add info such as line numbers easily without cluttering the grammars, and there's a central function in "gg.lua" intended to capture the stack of currently active parsers).
Metalua does reuse significant chunks of Yueliang source code. However, not at the relevevant levels for code analysis: Yueliang mimics the original lua 5.1 compiler's structure, which is great for many reasons including maintenance, but implies there's no AST construction in the process: compilation goes straight from token stream to bytecode.
