lua-users home
lua-l archive

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


> ...I find the performance of metalua is not that great.
> ... la loadstring is x100 faster than metalua lua

The static analyzer we use for live linting feedback in our Lua
IDE is based (roughly) on loadstring/file and a routine that
turns a proto structure into a Lua table structure (with all the 
actual analysis logic written in Lua).

I've considered switching to metalua, but was suspicious that 
it's performance would be insufficient for our needs. It sounds 
like those concerns were warranted.

I also wanted to be sure the linter's definition of valid Lua 
source was guaranteed to match that of Lua itself. It's all too 
easy to have a small discrepancy in the parser and end up with
an interpretation that doesn't match the "real" one. A number
of supposed Lua parsers out there miss corner cases* and fail
to parse source that's valid, mis-interpret its structure, or fail
to notice mistakes that should be compilation errors.

> ...if it is easy to transfer Lua compiler into AST with line info?
I've seriously considered doing this, in order to retain _character_ 
level info about the elements within a single line and retain a few
other pieces of information about the source structure that are
lost in the translation of source into bytecode.

I even wrote all the unit tests for the linter in terms of mappings
from Lua source to structured results so that if I ever decided to 
go make such a change, it'd be easy to rewrite the analysis logic 
and be pretty sure I didn't change its outward behavior.

So far, I've found the existing method sufficient (and the speed is
a nice perk, too), but every once in a while I run into something 
that gets me thinking about having a proper AST.

Dan Tull
Lua Tools Dev
Adobe

* the equals signs in block comments/quotes are one forgotten 
detail, but there are others