AST Redesign Proposal

[Edmund Lam]

Takes ideas from #158 (comment). Note that everything in this "tree" might actually be boxed and stored elsewhere, and this is just a representation of the ast layout.

Dependency Tree

As #342 mentions, we should have a better notion of dependencies to deal with importing. This issue proposes the idea of a dependency tree, and explains some of the inner details of how it might be implemented.

Dependency Node

struct File {
  src: Path, // contains the absolute (?) path to a file, used for diagnostics (can be generated lazily)
  components: Vec<Component>,
  dependencies: Vec<Dependency>
}
struct Dependency {
  prefix: Path, // The prefix of this dependency.
  file: Rc<File>, // holds a pointer to its file. Multiple dependencies can use the same file.
  self: bool, // does this import import the file itself as well?
  imports: Vec<Id>, // components being directly imported
  parent: Rc<Dependency> // might be unnecessary
}

A node in our dependency tree will be a Dependency. This will contain some information about what is being imported as well as the file being imported.

Resolving Dependencies

Imported crate names should be unique.

When converting a certain File to IR, if we encounter a statement like a::b::Comp, we can resolve it by looping through its dependencies and finding the one with a matching prefix, then making sure it exists.
If we just find something like Comp, we should look through all dependencies and see if they import a component with a matching name.

AST

This describes a redesign of the main AST (everything below file scope).

Nodes and NodeKinds

Like rust, we should have a notion of an Item for each "type" of node. These will be delineated by different syntax "levels". All nodes should contain information about where it was defined, etc. If a node doesn't contain such information, for error diagnostics we should recurse upward in the tree until we find a node containing that info. Nodes will also (if there exist variants) contain a kind field storing their corresponding NodeKind with specific information for each Node variant.

Some examples should include:

• Comp - Defines a component. Contains
  • sig: CompSig - Signature of a component, contains
    • attributes (#299)
    • Param - parameter definitions
  • body: Block - the body of a component.
• Block - A a block of code
  • Contains a list of statements.
  • This will allow astconversion to be made easier if we want rust's idea of Ribs - we can simply match on lets and blocks and add a new rib on their creation.
• Cmd - equivalent to rust's Stmt - a statement ended with a semicolon.
• Expr - Expressions
  • Associated ExprKind will contain variants like time expressions, binops, etc.
  • This will allow binop expressions to work on time and param without duplicating any code.

(draft)