-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Formatter depends on the AST, and some of the AST nodes have type-checking-type fields, so they depend on the type checker.
Ideally the formatter shouldn't depend on the type checker at all (directly and also indirectly).
This currently causes issues: when working on the type checker and the code doesn't type check yet, I can't format the code.
Formatting of WIP code can be done in other ways (e.g. have a separate Fir tree and use the formatter from that), but this issue will cause other problems in the future if we don't fix it soon.
Thoughts and ideas:
-
The simplest solution would be to make AST nodes parametric on extra info.
The problem though we have a lot of AST nodes, so this will add a lot of type parameters that we have to explicitly type in many places.
We don't support type synonyms yet, so we'll have to type the type arguments every time.
We could implement type synonyms now, but that's extra work that needs to be done twice (once in the interpreter, once in the compiler). If we could avoid it for now that might be the best.
-
We could allocate AST nodes in a vector (similar to tokens). That would give them unique ids, which we could then use to map AST node ids to extra info, in side tables.
This has some other advantages:
-
Once we start to do this it'll be easier to move more and more things to side tables, if needed. Side tables are nice because they can be allocated on demand and deallocated separately from the AST nodes.
For the current problem of formatter depending on type checker, the formatter would just not allocate the side table for type-checking-types of some of the AST nodes.
The side tables can also be quite compact. For example, if we give unqiue consecutive ids to the nodes with
Vec[Ty]fields, we could allocate one vector right away with the right size after parsing, and then lookups and updates would beO(1)with no hashing and eq comparisons and collusions in a hash table.
-