or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Magic symbol table (2020-12-16)
Discussion between Enrique and Hannes.
Problems discussed:
Current approach is simple:
In construction of a node with SymbolTableTrait, we run a pass that collects all symbols and stores it in a field in the node.
Consequences:
dtype
of a FieldAccess (which is a SymbolRef to a FieldDecl which has that information)/Post visit construction
The main problem is that we construct nodes bottom up, i.e. the node with the Symbol table is only constructed after the nodes with Symbols and SymbolRefs.
Handmade symbol table
Automatize this approach
visit
, create a SymbolTable when the user-defined visit is going to create a node with SymbolTableTrait. This could be indicated by a decorator by the user or derived from a required return-type-annotation.visit
Problems
Next day comment from Enrique
I've been thinking about our conversation from yesterday and it feels to me like we're trying to use ideas from different approaches that do not mix well, and thus we should decide which approach we follow. For example, if we want symbol tables embedded in the tree, then I guess we should either have immutable trees that are always visited in the right order, or we have lazy resolution of the SymbolRefs on access by traversing the tree upwards to look for a symbol table (like MLIR seems to do, which means we would need a link to the parent in the node).
Also, maybe we should try to use SSA for all temporaries from the beginning, since we probably need to do it anyway later for dataflow analysis and it would reduce the number of symbol names.
A more concrete idea we could try is to implement field validators which do not run automatically at initialization (e.f. @validator('dtype', auto=False)) and add an explicit validate() method that can be call at any time. In this way we could keep the natural post-order visitor to create nodes and still validators for fields which require parent information, calling children's validate() from the parent.
Isolated from above (2021-01-06)
C++ lambda example: create a new "root"-scope but inject some symbols from some other scope. In the case of c++-lambda global scope is injected and captures.
Automatic temporary context creation (2021-01-06)
Modification
I try to fix the following problem in the above design: SymbolRefs should point to the correct symbol at any time.
Features:
Symbolname
which is not in the tree."Addendum (Hannes)
It seems we don't need to store a SymbolTable object anywhere in the tree. Only during tree construction we need to keep it around (to create SymbolRefs), because we can just reference the SymbolNode from the SymbolRef directly. I don't see an advantage of going via SymbolTable. It maybe solves the problem of reconstructing the tree (but maybe we need to scan for removed Symbols in that case, so not sure…).
Questions
Can we automatically build the new SymbolTable + SymbolRefs in a Translator if we don't visit manually.
Here one category of Symbols is changed but the others should be there.
Here the SymbolTable (i.e. symbols inside) are not changed, but we don't know so probably we have to reconstruct. Then we have to automatically set the link to the new entry in SymRef2 which is not touched.
2021-01-21 Tried the above approach on oir2gtcpp
Here is a branch: havogt/symbol_table_experiments
It illustrates some problems. The main problem is that while constructing the new symbol table there is no tree yet.
This means you would attach to the symbol table but only later the node gets added to the tree, which could be inconsistent.
We discussed some ways construct the tree structure before hand, like
another approach for the same thing
Both have the same problem that you attach partly constructed nodes in an extra step.