Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: type system #5

Open
JeanJPNM opened this issue Jan 13, 2025 · 0 comments
Open

feat: type system #5

JeanJPNM opened this issue Jan 13, 2025 · 0 comments
Labels
enhancement New feature or request

Comments

@JeanJPNM
Copy link
Owner

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.

@JeanJPNM JeanJPNM added the enhancement New feature or request label Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant