Re: [ANNOUNCE] LuaParse 0.5

[Rici Lake <lua@...>]

On 27-Aug-04, at 2:32 PM, Nick Trout wrote:

> Ahhh. Well, some sort of mechanism so I can give the parser a script 
> and
> perhaps, optionally, a list of registered constants and functions (e.g.
> that are C registered); then parser returns a list of syntax errors 
> that
> I can deal with, just like a regular C compiler. Perhaps it returns a
> table of tables containing error type, description, line number, source
> file etc. This may be tricky because with Lua's first class function
> objects, functions could be reassigned and the code is correct. This is
> one of the problems of performing static analysis on a dynamic 
> language.

OK. lparse doesn't currently do line numbers, but the underlying lexer
can provide them; it would be easy enough to add that to the output for
errors. Currently, the errors are fairly well highlighted but previewing
constantly in a web browser is a bit of a pain; I've been thinking about
ways to integrate it with a more traditional IDE. I'm not sure what you
mean by "I can deal with" but I presume that you would like to give
your scripters some sort of useful feedback.

As far as registered constants and functions goes, lparse will flag
"undeclared globals" for you and you can provide it with a table of
acceptable globals; lvl initialises that table directly from the
global environment in place when the script starts.

lparse/lvl (currently) divides globals into three categories:

-- predefined (green) (the ones supplied to lparse in the initial 
globals table)
-- "declared" (black) globals which are assigned to at the top level 
prior to use
-- "erroneous" (inverse red) everything else

The heuristic for "declared" globals is imperfect, since the assignment 
must
take place earlier in the file than any usage, as opposed to earlier in 
execution.
However, I think good style would probably be to initialise any 
necessary globals
prior to use in a function. I actually use very few globals myself, and 
I find
it correctly identifies any misspelled locals.

I think it would be a good idea to flag constants (globals which "ought 
not" to
be assigned to) in the initial globals table. Even if this is not 
always an
error, it is quite possibly worth a warning.

My experimentation with visual linting was based on my hunch about how I
like to see things: I think people pick up on visual patterns pretty 
well,
and the various forms of highlighting in lvl are an attempt to provide
me (as the primary consumer) with visual feedback about my code. The 
current
colour scheme is arguably too subtle (too pastel, too inaccessible to 
the
colour blind, etc.) and I would be happy to distribute alternative 
stylesheets.
Everything is in the file "tnt.css" if you want to play around with it.

R.