Duansg commented on issue #3496: URL: https://github.com/apache/hertzbeat/issues/3496#issuecomment-3036746065
> > > hi [@Duansg](https://github.com/Duansg), I have a question about splitting G4 files. For implementation, should we split and parse it into two separate grammars, and then implement distinct Visitor for each to traverse the parse tree? Or should we use Antlr's priority mechanism to make the grammar rules clearer? Since I lack experience with complex expressions, I'm not sure if parsing different grammar rules within them will cause conflicts during development. Can Antlr's precedence mechanism completely handle situations with conflicts? After all, it seems a bit redundant in code that an expression needs to be parsed into two separate parse trees. > > > > > > Hi, sorry, I don't know why your reply was ignored, causing me to just see your message now, and in response to the question you posed, I'll tell you my experience and opinion so far. > > 1、 First of all: I agree with you that prioritizing ANTLR4 expressions according to their characteristics and priorities will ensure the convenience of subsequent debugging or type checking, semantic analysis, etc. But: as far as my use and understanding goes, there is no strong recommendation, either in the official instructions or in the community, to do a fusion of multiple different syntax rules. > > 2、 I think the prioritization rules you propose are for a single syntax, and there are serious limitations in practice when it comes to expressions in mixed syntax, or at least I think the risk of doing so is high, and I would strongly discourage it for the following reasons: > > ``` > > 1): severe lexical conflicts, difficult to handle the processing of different structures nested together. > > 2): Prioritization only applies to expressions, not to syntax rule switching, I think it's sufficient to use entry rule assignment, nested parsing, which are not inside the ANTLR prioritization mechanism. > > 3): readability is extremely poor, in a rule mixed into two grammars, the AST syntax tree will appear mixed nested structure, not only not "clear", but more "confusing", difficult to deal with the subsequent troubleshooting and type checking, semantic analysis and so on. > > ``` > > > > > > > > > > > > > > > > > > > > > > > > 3、 What are the considerations for your question about an expression parsing into two separate parse trees seeming a bit redundant? Or is it possible to expand on this, after all, my experience is limited as well, and I'd be happy to talk to and listen to your ideas. > > Summarize my opinion in one sentence: ANTLR4's prioritization mechanism I think can make the expression syntax within the same syntax parsing clearer, but it is not suitable for combining two complex syntax rules (SQL and PromQL) into one .g4 file and directly mixing the parsing, or you can try to build on the existing foundation of Hertzbeat by adding a mix of standard (SQL and PromQL) syntax rules and then think about other processing logic such as subsequent maintainability in conjunction with the logical context of Hertzbeat. Or you can try to add a mix of standard (SQL and PromQL) syntax rules to hertzbeat's existing base, and then think about the maintainability and other processing logic in the context of hertzbeat's logic. > > Understood. Considering that HertzBeat has already integrated various time-series databases, which may have different SQL-like syntaxes, I can imagine the complexity and the chaotic readability of parsing with a single parse tree. As support for more data source syntaxes is added, splitting the logic is indeed necessary. Of course, the work of adapting to multiple parse trees is time and energy consuming, this will likely be a long process. In the future, HertzBeat can achieve a smooth transition in this regard to ensure compatibility for upgrades from older versions. Thank you for your answer. @Cyanty Yes, you're right, it is indeed a long and complicated process :) But thank you very much for your answer, you can follow the movement of the community, so that when we have a follow-up related to the implementation of the same, and also participate in our construction :muscle: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@hertzbeat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@hertzbeat.apache.org For additional commands, e-mail: notifications-h...@hertzbeat.apache.org
