Closed sebastienros closed 5 years ago
Can you show some of the use cases, for tags being an extension to the parser?
Exactly like what the readme shows for custom tags. But for all tags.
So custom tags will be registered automatically!! If I'm not wrong this should be renamed to Parser Extensibility or shall we create a new one, and leave the PERF points for you 😄
FYI this benchmarks may interested https://github.com/lunet-io/scriban/blob/master/doc/benchmarks.md
I tried SuperPower and couldn't get faster than Irony. Right now I think we are in a good spot with perf because rendering is way much more important than parsing, and even comparing Parsin+Rendering we are faster than anything else.
The benchmarks from scriban are way out of date, and will send a PR with new results so they can be fixed. I will probably update our benchmarks first, and add scriban to the list.
Even though Fluid is the fastest liquid engine on .NET, there is still a lot to gain from having an optimized parser. Irony is very flexible to use but not fast enough.
We still need to support parser extensibility, probably giving an access to the decision tree after tokenization, so we can add custom tags with special constructs. This could even be done in a way that all the tags are actually an extension to the parser, such that the main parser logic will be to detect tags and blocks, and switch to a tag specific implementation to parse the content.