You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To further facilitate writing raw mlog, I propose adding a type system to statically analize scripts and provide useful errors in case of type mismatches, provide more accurate completions (e.g. you can't sense @air on a building, so it would have a lower precedence and appear later in the completion list), and give the user a better idea of what the built-in variables hold (like how @second is a float instead of an int).
There are a few considerations I'd like to make before proceding:
Since @counter can be manipulated in ways that are very hard if not impossible to statically analyze, trying to use control flow graphs to perform operations like type inference may be impractical. Instead, the easier approach would be to construct a global dependecy graph to resolve variable types relative to all of their assignments. The tradeoff is, of course, that the inference is less accurate for variables that only change their type in a few predictable places but nowhere else. Like this:
# item could be ItemType or null
sensor item switch1 @config
jump later notEqual item null
set item @copper # default value
later:
# item will still have an inferred type of ItemType | null
# despite the condition above
print item
As a consequence of the reduced accuracy, the language server will only complain if the types do not have any overlap and the instruction is not able to perform a typecast to successfully execute. Meaning that subtle errors like forgetting to check if a variable is null before using it will not be caught. Bellow is a brief example of what it could be like.
# this will error because @air
# cannot be used as a sensor key
sensor value @unit @air
# this will be allowed since strings
# can be cast into numbers
op add value 0 "string"
# this will error because units cannot be cast
# into buildings
radar enemy any any distance @unit true value
# allowed for the same reason as before
write "string" cell1 0
In the end the types are like hints at what a variable could be instead of strong guarantees about the program's integrity and behavior.
For those who may want stronger guarantees, it is recommended to go use one of the available compilers.
The text was updated successfully, but these errors were encountered:
To further facilitate writing raw mlog, I propose adding a type system to statically analize scripts and provide useful errors in case of type mismatches, provide more accurate completions (e.g. you can't sense
@air
on a building, so it would have a lower precedence and appear later in the completion list), and give the user a better idea of what the built-in variables hold (like how@second
is a float instead of an int).There are a few considerations I'd like to make before proceding:
Since
@counter
can be manipulated in ways that are very hard if not impossible to statically analyze, trying to use control flow graphs to perform operations like type inference may be impractical. Instead, the easier approach would be to construct a global dependecy graph to resolve variable types relative to all of their assignments. The tradeoff is, of course, that the inference is less accurate for variables that only change their type in a few predictable places but nowhere else. Like this:As a consequence of the reduced accuracy, the language server will only complain if the types do not have any overlap and the instruction is not able to perform a typecast to successfully execute. Meaning that subtle errors like forgetting to check if a variable is
null
before using it will not be caught. Bellow is a brief example of what it could be like.In the end the types are like hints at what a variable could be instead of strong guarantees about the program's integrity and behavior.
For those who may want stronger guarantees, it is recommended to go use one of the available compilers.
The text was updated successfully, but these errors were encountered: