Compatblity

One of the big reasons behind the creation of Fuse is safety and ease of development in larger code bases. But another reason is to keep some ideal amount of compatibility with the existing LUA codes other than the ability to load and on this page, we are going to discuss what decisions have been made to achieve this balance between safety and compatibility.

Agenda

Lua language has proven to be one of the most backward-compatible languages that have ever existed and it maintained a surprising amount of backward compatibility when migrating to newer versions which is an astonishing achievement on their side. Unfortunately, it comes at the cost of keeping some of the decisions that made sense in the early days of the language and ever since have lost their usefulness.

Syntax

Fuse syntax tries to be compatible with Lua 5.1 to some extent but we do not want to get 100% compatibility at the cost of inheriting all of the technical debt. Instead, we are aiming for a similar enough language that makes porting current Lua codebases one module at a time possible. To provide such interoperability between Fuse and its target runtimes we have made sure to only support the highest common denominator between all of the different flavors of Lua so we can do things such as writing our code to run on Lua 5.4 in customer’s machine and have it on LuaJIT in production server.

Limited Global Scope

Having global scopes in your files and especially having them as the default behavior of variable definition is reasonable in smaller codebases but since Lua is one of the most loved scripting languages and is so easy to embed in any project we are seeing a multitude of projects that have adopted Lua for their scripting needs as their domain-specific language.

We think that global scopes by default aren’t one of those features that would help us to achieve our goals Since it only makes sense in the context of header files, which may be one of the reasons behind the origin of this decision from Lua team in the birth of the language. It would’ve made sense for the early days of Lua but with the mass adoption of the language, We have seen a lot of abuse via bad use of global scope (or at times naive use).

Other than that it makes it hard to reason about dependencies and the origin of global variables in any given project.

But we cannot entirely remove global variables even tho it makes the inner workings of a reliable module system much easier and straightforward. There are already a lot of libraries written for Lua that are using the global scope and by isolating Fuse from accessing to global scope we are definitely going to break some legacy codes which is something we do not desire.

So what we propose is keeping the global scope but it is no longer the default scope of our variables, For example instead of doing the following in the Lua:

global_variable = "I'm a global variable"
local local_variable = "I'm a local variable"

We write this:

global_variable = "It will raise an error in compilation!"
global global_variable = "I'm a global variable"
const local_constant = "I'm a local constant"
-- or
let local_variable = "I'm a local variable"

As you can see in Fuse we have to explicitly define a variable as global with the keyword otherwise we get an error since it is the same as trying to write to an undefined variable.

We also don’t allow access to global variables via the use of their name alone, Since global variables are side effects in nature and are unpredictable in the code what variable and with which type exists at this point in the program. These variables are really hard to keep track of since they can be defined inside of functions, files, chunks, or many other possible places. To accommodate this issue we only allow users to access global variables using the global keyword or _G table.

As a result instead of writing this:

my_global = "HI!"

print(my_global)

We do this:

global my_global = "HI!"

print(_G.my_global)
-- or
print(global.my_global)

global when used as a table acts as an alias to _G for readability reasons.

Keep in mind that the _G table always has any type and it is literally impossible to type the global scope at compile time but it is possible to either cast the variables into a known type or create a type definition for global scope and so the compiler can infer the types from that but it won’t guarantee the existence of the given variable and it just provides auto-complete and type checking.

Features beyond Lua 5.1

We have chosen the Lua 5.1 as our base syntax to build upon. This version of Lua is the most available set of features in the Lua ecosystem since anything that works in 5.1 can also work in 5.2, 5.3, 5.4 and Luau but it doesn’t mean that we don’t backport any features from newer versions of Lua or ideas from Luau interpreter that can work as a syntax sugar with our Lua 5.1 limitation that we applied to ourselves. There are a few notable changes. Mainly we don’t have pack and unpack functions anymore, instead, we are using table.pack and table.unpack to make it consistent between different target versions. Other than that there are also some new features backported from newer releases of Lua and some completely new features that are missing from every version of Lua, Things like type support, string interpolation, traits, pattern matching, array deconstruction, += -= *= /= operators and better error handling(see Error Handling section) among many others.

Differences with Lua 5.2

* items whose status is marked with an asterisk are supported in Fuse but don’t have universal support when used from some versions of vanilla Lua

Differences with Lua 5.3

* items whose status is marked with an asterisk are supported in Fuse but don’t have universal support when used from some versions of vanilla Lua

Differences with Lua 5.4

Differences with Luau

Improve this page