Skip to content

AST types shouldn't depend on type checker types #252

@osa1

Description

@osa1

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 be O(1) with no hashing and eq comparisons and collusions in a hash table.

Metadata

Metadata

Assignees

No one assigned

    Labels

    compilerFir compiler written in Fir

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions