Lua runtime when transpiling to 80.3 Go
LuneScript is a project that started development as a Lua transcompiler. And in order to take advantage of Lua's assets, LuneScript also supports actions linked with Lua.
This operation that links LuneScript and Lua is also available when transcompiling to go. In other words, it works in conjunction with Go and Lua.
To achieve this, we need to link the Go and Native lua runtimes. Even if the LuneScript code does not use the linked operation with Lua, the Lua runtime function is used internally, so the link with the Lua runtime cannot be separated.
The interaction between LuneScript and Lua is an important feature of the nature of Lua's transcompiler. On the other hand, if LuneScript is considered as a Go transcompiler, it cannot be said that the cooperation with Lua is so important.
In addition, there are the following advantages of go.
- A single file that operates independently can be created without depending on the library of the execution environment.
- Supports cross-compilation to various environments
The above advantages are lost when the Lua runtime needs to be linked.
Although the Lua runtime has a configuration that is less dependent on the environment, it becomes a major hindrance to maintaining the above advantages.
Therefore, it is possible to execute transcompiled code without linking with the Native Lua runtime.
Using gopher-lua
gopher-lua is a Lua runtime implemented in go. Avoid linking with the Native Lua runtime by using gopher-lua.
To use gopher-lua, specify -tags as an option at go build.
go build -tags gopherlua
Specifying this option switches the Lua runtime from Native Lua to gopher-lua.
Notes on gopher-lua
When using gopher-lua, the specification of Lua runtime is restricted by the specification of gopher-lua.
Specific examples are given below.
- lua version is 5.1
- Some APIs such as string.dump are not available
- Cannot use Lua libraries that are not pure Lua, such as luasocket
- Slower than Native Lua
If you don't use LuneScript and Lua linkage, you don't have to worry about it, but you should be aware that there are differences between Native Lua and gopher-lua.
Other Lua runtimes
There are several types of Lua runtimes implemented in go.
The following are typical examples.
yuin/gopher-lua is the implementation used this time. Among the representative examples, this is the only implementation that was able to run LuneScript's self-hosted Lua code.
Azure/golua appears to be a project launched by Microsoft. I expected it to be based on lua5.3, but when I actually ran it, it didn't work at all (I couldn't parse Lua). In addition, since the github repository is Archived, future development cannot be expected.
Shopify/go-lua is developed based on lua5.2. A simple Lua script works, but I couldn't load lua which self-hosts LuneScript. For this reason, it was expected that there would be a problem with compatibility, so we decided not to adopt it in LuneScript this time.
I tried several Lua implementations by go this time, but it was a pity that there were few Lua implementations that supported the level of compatibility that allowed LuneScript to be executed.
I also thought that if I implement Lua in the future, I might be able to use it as a test case to check Lua compatibility by checking whether LuneScript works.
However, if it doesn't work, it's not easy to find out why it doesn't work, so it's not very useful as a test case, so it's not realistic.