Validation

Goal

Make it easier to extend the syntax and make compiler easier to work with.

Overview

This should unblock #28

Currently, the individual node parsing methods perform in-place validation on the syntax. For example, the identifier parser may throw an undefined variable syntax error if it cannot identify the variable.

https://github.com/ballercat/walt/blob/296f1cb1d19188c29e63ea96b6873df94781ba20/src/parser/maybe-identifier.js#L48

This is OK, but the more syntax is extended the harder it is to extend the behavior. In the above code, the undefined variable handler is overwritten to silence the error while parsing function arguments(while parsing the parent node). Instead of doing the above, let’s have another step before the generator, a static type/validator checker.

The final pipeline will look like this:

Tokenizer -> tokens -> Parser -> ast -> Static Checker -> ast/dag -> Generator -> ir -> Emitter -> bytecode

Initial implementation would only handle Identifier nodes. This means the static checker would do the following:

• Ensure the identifier is valid/in-scope
• Patch nodes to attach correct metadata, like global/local indexes, type definitions, function indexes and table pointers
• throw syntax errors if the identifier is undefined and only do so in correct context. For example, it should be fine for an identifier to be undefined in a function definition because that is the first node it’s defined in.
• Code generation needs to be moved entirely to its own step. Currently, functions generate IR in-place but this will need to change.

[ballercat]

I think once the project is mature and stable enough something like that should be possible. Right now I’d like to keep the discussion focused on implementing the changes outlined in the issue.

[ballercat]

I’ve unblocked this with #56 and implemented a basic validation step.