Conversation
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Co-authored-by: Copilot <copilot@github.com> Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
There was a problem hiding this comment.
Suggestion: Since we need all of this code in other parts of the parser (not just the lookahead), it might make sense to move it to the parser parent directory.
There was a problem hiding this comment.
FTM a lot of stuff is inside the generator package. Only the Runtime ATN is in the parser package.
| "typefox.dev/fastbelt/generator" | ||
| ) | ||
|
|
||
| func EmitMarkdownSource(pkgName string, rtn *RuntimeATN, tokenTypeNames map[int]string) generator.Node { |
There was a problem hiding this comment.
Suggestion: This part of the code should live in the internal part of the framework - adopters shouldn't be able to call this function IMO.
| // pkgName – Go package name for the generated file (e.g. "myparser") | ||
| // funcName – name of the generated constructor function | ||
| // importPath – import path of the allstar package (e.g. "typefox.dev/fastbelt/parser/allstar") | ||
| func EmitGoSource(pkgName, funcName, importPath string, rtn *RuntimeATN) generator.Node { |
There was a problem hiding this comment.
Suggestion: This part of the code should live in the internal part of the framework - adopters shouldn't be able to call this function IMO.
Co-authored-by: Copilot <copilot@github.com> Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Co-authored-by: Copilot <copilot@github.com> Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
| Action_Alternatives_1 ATNDecisionId = 0 | ||
| Action_Group_2 ATNDecisionId = 1 | ||
| Alternatives_Group_2 ATNDecisionId = 2 | ||
| Alternatives_Group_3 ATNDecisionId = 3 |
There was a problem hiding this comment.
The counter inside the name looks broken...
There was a problem hiding this comment.
The counter refers to the index of all parts in a rule. Only a few are used for the decision map.
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
|
|
||
| func (rb *ATNRuleBuilderImpl) MakeBlock(alts []*ATNHandle) *ATNHandle { | ||
| for i := 0; i < len(alts)-1; i++ { | ||
| handle := alts[i] |
There was a problem hiding this comment.
@msujew Not very sure about the original implementation...
May need to redo it...
There was a problem hiding this comment.
MakeBlock is about concatenation, not alternatives.
Is this so much faster? I would prefer simple code.
Modelling middleware for the ATN could be a thing, that could be designed to optimize the ATN.
There was a problem hiding this comment.
Right, and the idea is to skip 254-255, 256-257, etc. since they don't serve any value in the ATN. In the end, this makes the subset construction algorithm - and all other algorithm that need to traverse the ATN - slower. I would assume by quite a significant margin actually, with more gains the deeper the grammar becomes.
IMO, we should do everything, even if complicated, to improve the performance of the runtime-code in favor of more complexity in the compile-time code.
And to be honest, the simplification code isn't that difficult, though feel free to add further comments here.
Modelling middleware for the ATN could be a thing, that could be designed to optimize the ATN.
Sounds more complex than just adding the optimization in there actually ;)
There was a problem hiding this comment.
True. The middleware thingy sounds more complicated, when looking only at this single optimization. When we would add more of these optimizations the code becomes more unreadable. The middleware or middleend was an idea to introduce a optimization module.
But I remember that there is also a minimization strategy for DFAs. Maybe we can do something similar here?
Middleware or a big optimization step afterwards, so or so, I like this code here to be in a simple shape. But I could reintroduce the code with a explanation and a TODO, that we can refactor in a future PR.
There was a problem hiding this comment.
I'd be a bit hesitant to change the structure of the ATN too much. After all, we need it later to perform code completion and error recovery.
There was a problem hiding this comment.
Then let‘s postpone the refactoring until we have the necessary features with tests.
| Start: Property+=Rule*; | ||
| Rule: Name=ID; | ||
| `)) | ||
| RequireATNRecognizes(t, atn, rules, tokenTypes, "Start", []string{}, 1) |
There was a problem hiding this comment.
Add tests with 2 or more paths…
msujew
left a comment
There was a problem hiding this comment.
Looking really promising already, just a few comments, see below 👍
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>

There is a big Compile Time ATN for construction and a slim Runtime ATN.
I also added a Markdown generator to be able to debug the ATN visually.