I once needed to fix this issue [1] but the fix was rejected because it introduced worse performance than it ideally should. As mentioned in the comments, the current approach followed in the current parser is the reason for that. I mean if we designed the grammar differently, we could've had fixed the linked issue a long time ago as Julian already attempted to fix it.
Having that said, we might go with *antlr* only to have that "better" approach for our parsers. We don't have to dump our current parser of course as *antlr* can be optionally activated. [1] https://issues.apache.org/jira/browse/CALCITE-35 Thanks, Gelbana On Thu, Aug 22, 2019 at 10:05 AM Danny Chan <yuzhao....@gmail.com> wrote: > Thanks, Julian. > > I agree this would be a huge work, but I have to do this, I’m just > wondering if any fellows here have the similar requests. > > Best, > Danny Chan > 在 2019年8月22日 +0800 PM2:15，Julian Hyde <jh...@apache.org>，写道： > > ANTLR isn’t significantly better than, or worse than, JavaCC, but it’s > different. So translating to ANTLR would be a rewrite, and would be a HUGE > amount of work. > > > > > > > > > On Aug 21, 2019, at 8:01 PM, Danny Chan <yuzhao....@gmail.com> wrote: > > > > > > Now some of our fellows want to do the syntax promote in the WEB page, > and they what a parser in the front-page; The ANTLR4 can generate JS parser > directly but JAVACC couldn’t. > > > > > > So I’m wondering do you have the similar requests ? And do you think > there is necessity to support ANTLR4 g4 file in Calcite ? > > > > > > > > > Best, > > > Danny Chan > > >
