> 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)
