lua-users home
lua-l archive

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

On Sun, Jun 13, 2010 at 11:02 PM, Jon Akhtar <> wrote:
> I have been working on a plugin for IntelliJ IDEA and the other
> JetBrains IDE's. for the past 2 months.

Hi Jon.  Looks like a good start, and I encourage the building of
better code analysis tools in Lua.

Here's one of my latest experiments which shares similarities to yours:

It reuses some of the Metalua libraries to convert Lua code into an
AST, analyzes the AST while decorating it with information classifying
variables and code constructs, and renders the result as annotated
source code for display.  Currently it renders as HTML/CSS/JavaScript
rather than a text editor, although there's no reason the analysis
results couldn't be incorporated into a text editor like SciTE.

This was just a proof-of-concept, as I wrote it up in less than a day
and it's quite short and entirely in Lua; however, as seen from the
example, it was quite easy to make this functional by reusing what's
already available from Metalua libraries and the web browser.

If I had the time for it, I would like to add many things beyond this,
which may also be of interest in IntelliJ.  Foremost of these, I would
like it to do a data flow analysis of the code to statically infer and
display, when possible, types and values of all instances of
variables, dependencies between variables, and conflicts.  That
analysis possibly could be combined with run-time profiling
information.  This will help the user better understand new Lua code
and also detect code involving inferences that likely conflict (e.g.
"string.format('%d', x); table.insert(x,1)" very likely conflicts on
x).  (Such analysis code might also be reused in other projects too
[1], and some initial directions there were taken in luaanalyze [2].)

My opinion is that if a human can make useful inferences about Lua
code, then so can a computer, and the computer can assist the user.
Due to the dynamic nature of Lua, the inferences may not be 100%
confident, but inferences can be qualified by confidence levels, and
inferences that are 90-99% confident are good enough to be useful for
a linter and inspection tool (unlike perhaps in an optimizing compiler
that requires perfection).  Reasonable assumptions such as standard
global functions not being redefined are often acceptable here.

[2] (bottom of page)