-
Notifications
You must be signed in to change notification settings - Fork 84
Description
For some time now, i've been wondering if adding a typer to polymod would be a good idea, since it would help produce better errors, and even turn some runtime errors in to compiletime errors. I know that we can optionally use hscript_typer, however we do not use it to create a better AST, we only use it for errors (not even any warnings). Additionally, I think the same way we now have hscript be a part of polymod instead of a library, we can do the same for the typer. That way there also wouldn't be any errors, because polymod and hscript_typer rely on a different hscript
Here are some of the advantages of using a typer, i have thought of:
-
Compiletime warnings/errors:
- Type checking can be done, and result in compiletime errors, instead of runtime errors. Currently we aren't even doing any type checking except when checking whether certain classes exist when trying to import them.
- Give warnings when using deprecaded functions.
- Check when someone tries to change a
finalvariable at compiletime instead of runtime - Give an error when using a non existant variable or a variable out of scope
-
Abstracts:
- Abstracts can work much better when using a typer. To access instance functions the user wouldn't be required to access them in a static way, i.e.
AbstractFoo.bar(abstractFooInstance, ...), instead they could doabstractFooInstance.bar(...). - Certain checks that are currently done everytime we try to access static fields of abstracts, can be done once at compile time, that way improving performance.
- Abstracts can work much better when using a typer. To access instance functions the user wouldn't be required to access them in a static way, i.e.
-
Macros (If they are ever going to be implemented):
- In macros we would have type information, which we wouldn't have else.
As mentioned in some of the points above, we can do some checks and compiletime instead of runtime, that way we can also create an "optimized" AST, that could be interpreted faster, which I think could be done for some of the abstract stuff, for example instead of having to do the check whether a static field of an abstract is in abstractClassStatics at runtime we just change the AST so that we instantly get from abstractClassStatics
We could potentially even go from interpreting the scripts to compiling them. That way we could improve performance even more, as well as make loading scripts faster, since they we wouldn't need to parse and type them everytime. We would only need to do that if the scripts have changed.