Heh, well it is a flaw in the language design :). I already knew that. Ok, I think I have an idea on what I can do at least. You've given me some good hints. I prolly should look at the SqlNode tree after parsing, maybe. I'll see what I can do.
Thanks! On Sun, Nov 3, 2024 at 8:26 PM Mihai Budiu <mbu...@gmail.com> wrote: > 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 > > >
