A linter in luac

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

A linter in luac

Pedro Tammela-2
I believe luac is the perfect tool to have a linter for Lua.

Given the current status for luacheck, I think it seems the perfect time to do so, given that it's such a handy tool.

Pedro
Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Luiz Henrique de Figueiredo
> I believe luac is the perfect tool to have a linter for Lua.
> Given the current status for luacheck, I think it seems the perfect time to do so, given that it's such a handy tool.

luac does two simple jobs: save precompiled scripts and list byte
codes. How is that related to linting?
luac does not seem related to luacheck. What exactly do you have in mind?

Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Philippe Verdy
offline compilers can make precise reports that would take too long to compute in a JIT.
For C/C++, lint has been integrated in compilers since long. Luac could implement many more checks while not just compiling. It could support additional notations and provide a way for IDE to integrate these checks by allwing annotations used by the compiler (which would in turn be able to use better optimization as well, knowing that the code will be used in a more precisely described environment that includes also the dependencies).
For now Luac just works on static analysis and JIT in Lua has to make superficial analysis due to time/resource constraints.
Luac also is not meant to be used on small devices: applications are prepared in a more solid environment with much more capabilities than those supported in the Lua runtime.


Le ven. 18 oct. 2019 à 21:45, Luiz Henrique de Figueiredo <[hidden email]> a écrit :
> I believe luac is the perfect tool to have a linter for Lua.
> Given the current status for luacheck, I think it seems the perfect time to do so, given that it's such a handy tool.

luac does two simple jobs: save precompiled scripts and list byte
codes. How is that related to linting?
luac does not seem related to luacheck. What exactly do you have in mind?

Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Philippe Verdy
Anyway, I hope one day we'll have an integration of Lua in premium development environments like Eclipse or Visual Studio and similar so that Lua plays well in a much larger ecosystem of solutions that will also help in design management, refactoring, adaptation of code to more specific demands. This has been done for PHP, Javascript, Python, Perl, Java, C, C++... And we still lack that for opening the integration of Lua with many more environments (including multi-tiered systems, not just basic client-server or just some binding interface to external libraries).

Le ven. 18 oct. 2019 à 22:20, Philippe Verdy <[hidden email]> a écrit :
offline compilers can make precise reports that would take too long to compute in a JIT.
For C/C++, lint has been integrated in compilers since long. Luac could implement many more checks while not just compiling. It could support additional notations and provide a way for IDE to integrate these checks by allwing annotations used by the compiler (which would in turn be able to use better optimization as well, knowing that the code will be used in a more precisely described environment that includes also the dependencies).
For now Luac just works on static analysis and JIT in Lua has to make superficial analysis due to time/resource constraints.
Luac also is not meant to be used on small devices: applications are prepared in a more solid environment with much more capabilities than those supported in the Lua runtime.


Le ven. 18 oct. 2019 à 21:45, Luiz Henrique de Figueiredo <[hidden email]> a écrit :
> I believe luac is the perfect tool to have a linter for Lua.
> Given the current status for luacheck, I think it seems the perfect time to do so, given that it's such a handy tool.

luac does two simple jobs: save precompiled scripts and list byte
codes. How is that related to linting?
luac does not seem related to luacheck. What exactly do you have in mind?

Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

markjynx
A good program is like a good function: it does one thing and does it
well.
This (UNIX) philosophy leads to small, efficient, reliable, modular and
safe functions and programs.
Both Eclipse and Visual Studio are horrible, bloated, nearly
unmanageable software.
I hope luac never even approaches that direction.

Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Pedro Tammela-2
In reply to this post by Pedro Tammela-2
> For C/C++, lint has been integrated in compilers since long. Luac could
> implement many more checks while not just compiling.
> [...]
> Luac also is not meant to be used on small devices: applications are
> prepared in a more solid environment with much more capabilities than those
> supported in the Lua runtime.

That's my line of thought.

Pedro
Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Philippe Verdy
Le sam. 19 oct. 2019 à 20:09, Pedro Tammela <[hidden email]> a écrit :
> For C/C++, lint has been integrated in compilers since long. Luac could
> implement many more checks while not just compiling.
> [...]
> Luac also is not meant to be used on small devices: applications are
> prepared in a more solid environment with much more capabilities than those
> supported in the Lua runtime.

That's my line of thought.

When I said that, I did not mean that the Lua runtime itself should not embed a limited compiler that does not perform some essential security validation checks.
This means that we could have two versions of Luac: one meant for development in solid environments and lot of debugging and tracing facilities, and hinted optimizations that could be patiently built and tested extensively by developers.

And another one to be deployed: most scripts to compile directly on target devices however would be extensively tested or would be created by basic code generators, that would finally get compiled locally just to improve a bit their performance, but may be still depending on a solid interpreter being agressive on safety checks, but not using any advanced hints (things like runtime profilers could be removed, they are very hard to support, instead a good compromise based on good programming practices could just make reasonable choices; things that can be removed are when there are several generated code representations: such compiler would just use the most generic choice, even if the generated code repeats more tests than needed and the generated code does not use the full set of features offered by the runtime and used only by applications developed and compiled on solid environments).

These two compilers may just use the same source, but with some precompilation pragmas/directives that would include or not some advanced parts that are not strictly necessary. For example the simpler generator in the basic compiler generated would remove support for interfacing native system APIs and libraries, depending only on 100% pure lua; support for efficient multithreading could be replaced just by assuming (and making sure) that the code will use a single thread; it would not permit direct interaction with concurrent native threads, using the API prebuilt in a solid environment should be enforced. A core subset of the Lua API could be proposed by such compilers, the unsupported code would fail or would be supported by partial emulation in 100% pure Lua, even if it is slower (e.g. extended support for regexps instead of basic Lua patterns, or support for additional internal subtypes for numbers, or high precision timers)
Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

szbnwer@gmail.com
In reply to this post by markjynx
hi all! :)

markjynx:
+1!!! :D

bests to all! :)

Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Egil Hjelmeland
In reply to this post by Luiz Henrique de Figueiredo
Den 18.10.2019 21:45, skrev Luiz Henrique de Figueiredo:
>> I believe luac is the perfect tool to have a linter for Lua.
>> Given the current status for luacheck, I think it seems the perfect time to do so, given that it's such a handy tool.
> luac does two simple jobs: save precompiled scripts and list byte
> codes. How is that related to linting?
> luac does not seem related to luacheck. What exactly do you have in mind?
>
An option to list global variables could be a low hanging but useful
feature.

I made a script
https://github.com/hjelmeland/globals/blob/master/globals.lua that parse
luac output for that purpose. I would not mind if it was made obsolete.

Egil



Reply | Threaded
Open this post in threaded view
|

Re: A linter in luac

Luiz Henrique de Figueiredo