You cannot have the parser use the type information to decide the precedence - unless you do type inference during parsing, which no modern compiler is doing. Or a very small subset of type analysis, enough to give you the information you need. Languages like C, for example, keep different symbol tables for type names and other identifiers, so the parser can disambiguate dynamically when an identifier is seen whether that's a type or a normal identifier.
On the other hand, If your parser has decided what the operator is, then you don't have a choice later. I think you are pointing to a flaw in your language design. You want the syntax to accept a superset of the legal programs, then the type analysis to throw away illegal programs. Why do you need two different precedences? Make them the same precedence, and then let the type analysis disambiguate. Mihai ________________________________ From: Stephen Carlin <scar...@cloudera.com.INVALID> Sent: Sunday, November 3, 2024 8:15 PM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Operator overloading for SqlSyntax.BINARY Sigh, I did try making || a function. But when I do, I have two choices, neither of which worked: 1) Make it a "ConcatOr" Function to handle both and defer which one to use until RelToSqlConverter. That didn't work because of order of operations. The precedence is difference for "or" and "concat". So by the time it hits RelToSQlConverter, the precedence has already been decided. 2) Make 2 different operator functions. Maybe it's possible? But that would involve quite a few parser changes to do. I was hoping to keep that at a minimum. The SqlBinaryOperator function in Parser.jj is here the magic happens and, by the function name, it needs an operator, not a function. I even tried changing the Parser.jj file to return an SqlOperator instead of an SqlBinaryOperator, but I hit an assertion when it tried to establish precedence, which has hardcoded "instanceof" implementations on how to decide precedence. The only idea I had was in that filter function I mentioned above. But even then...has precedence been decided already? I'm not sure. I do realize that the syntax we have is a bit strange in terms of operator overloading. I do potentially have the option to say "we are not supporting the syntax as/is" for the next major implementation, and I somehow think that's gonna be the option. But you know users...they like backward compatibility. So hoping to avoid that. Thanks for your input! If you can think of something else, I appreciate the help! On Sun, Nov 3, 2024 at 7:42 PM Mihai Budiu <mbu...@gmail.com> wrote: > In Calcite type inference happens during validation, much later than > syntax checking. > So you cannot decide just based on "syntax" which || is being invoked. > Moreover, the presence of type casts may make this tricky. Consider true > || 'false'. Depending on the implicit casting rules, this may be > interpreted either as a Boolean or as a string. > But indeed, if you have your own SqlOperatorTable, and given the existing > implicit casts rules, you should be able to implement your desired behavior. > > I suspect that Calcite indeed is not prepared to disambiguate overloaded > operators based on type - only overloaded functions. > > But since you have your own SqlOperatorTable, can you make || be a > function? I think this only may make a difference if you plan to convert > the representation back to SQL using RelToSqlConverter - then having it be > a FUNCTION would cause problems. > > Note: I haven't tried the solution I am proposing - it may not work. > > Mihai > ________________________________ > From: Stephen Carlin <scar...@cloudera.com.INVALID> > Sent: Sunday, November 3, 2024 2:57 PM > To: dev@calcite.apache.org <dev@calcite.apache.org> > Subject: Operator overloading for SqlSyntax.BINARY > > Hi all, > > I'm currently trying to implement Calcite on my already existing SQL > syntax. I created my own SqlOperatorTable and I overrode the > lookupOperatorOverloads method. And things are working pretty well. > But.... > > I have a situation with the "||" operator. In my syntax, it can be used as > either "concat" or "or". I thought this was gonna be an easy task within > the framework. According to my syntax rules (for better or for worse), if > both parameters are boolean, it should be an "or". Otherwise, it should be > a "concat". > > My plan was to return both operators in the lookupOperatorOverloads > operator list and let the Calcite framework do its thing. That method does > not have access to the parametrs. But I did see a > filterRoutinesByParameterTypeAndName method which would do exactly what I > want! However, the first check in the method is "is it an > SqlSyntax.FUNCTION", which...it is not, it's a BINARY. So I'm unable to > use this filter and I don't have a way to choose based on parameters. > > I have to use 2 different operators because the precedence of OR is 22 and > CONCAT is 60. > > I hope this is enough of an explanation of my problem. Any suggestions on > how to solve this? I have my own Parser.jj that I'm using so I can > theoretically manipulate code there, but I'd like to keep manipulations > there to a minimum. Also, is there any reason why the filter routine only > wants to filter functions and not binary operators? > > Thanks in advance, > > Steve >
