You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
structFile{src:Path,// contains the absolute (?) path to a file, used for diagnostics (can be generated lazily)components:Vec<Component>,dependencies:Vec<Dependency>}structDependency{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 importedparent: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.
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)
The text was updated successfully, but these errors were encountered:
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
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 likea::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).
Node
s andNodeKind
sLike 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 akind
field storing their correspondingNodeKind
with specific information for eachNode
variant.Some examples should include:
Comp
- Defines a component. Containssig: CompSig
- Signature of a component, containsParam
- parameter definitionsbody: Block
- the body of a component.Block
- A a block of codeCmd
- equivalent to rust'sStmt
- a statement ended with a semicolon.Expr
- ExpressionsExprKind
will contain variants like time expressions, binops, etc.(draft)
The text was updated successfully, but these errors were encountered: