The issue that I'm looking at is about UDF specification. Currently, we use this:
FunctionDeclaration::=<DECLARE> <FUNCTION> Identifier ParameterList <LEFTBRACE> Expression <RIGHTBRACE>, which enforces the "SelectExpression" to be put into parentheses so it can be matched by "OperatorExpr" (see the specification of Expression in my previous email). This I think probably is not necessary. Similar syntax without explicit parentheses is available in AQL. There was a test case for this and it's disabled for now. As suggested by Mike, I went through the usages of "Expression". I guess the separation is to make sure all "SelectExpression"s are parenthesized if it's not a top-level query. For that purpose, maybe I can change the Function Declaration to this: FunctionDeclaration::=<DECLARE> <FUNCTION> Identifier ParameterList <LEFTBRACE> SelectExpression | Expression <RIGHTBRACE> ? Best, Xikui On Thu, Mar 15, 2018 at 10:45 AM, Dmitry Lychagin < [email protected]> wrote: > Xikui, > > "(" SelectExpression ")" is permitted by the Subquery() production, and > Subquery() itself is one of the alternatives in the > ParenthesizedExpression(). > > What is the compilation issue you were trying to solve? > > Thanks, > -- Dmitry > > On 3/14/18, 11:52 PM, "Mike Carey" <[email protected]> wrote: > > Not sure, but I don't think this is (nearly) sufficient context/info to > see what's going on. With the current factoring of things, any other > place that includes Expression is not going to allow a SelectExpression > to appear directly as an Expression. Your change would - which might > be > a major change, syntactically, that might lead to a variety of > ambiguities. Without looking at the whole grammar one can't tell. I > would guess that if you look, you may find that you can have a > SelectExpression as a query if and only if its enclosed in parentheses, > which might be by design to avoid ambiguities. Have a look at that.... > (Basically, look at the other uses of Expression in the grammar - > and/or > look to see if "(" SelectExpression ")" is permitted if you follow > through the grammar from Expression. > > > On 3/14/18 8:59 PM, Xikui Wang wrote: > > Dear Devs, > > > > I'm trying to fix a compilation issue with the subquery in SQLPP and > got a > > question about the specification of "Expression". Here is the current > > grammar of "Query" and "Expression" in SQLPP: > > > > Query::=( Expression | SelectExpression ) > > Expression::=( OperatorExpr | CaseExpr | QuantifiedExpression ) > > > > I'm wondering why "SelectExpression" is not in the specification of > > "Expression" but in "Query". When I looked back to the AQL > specification, I > > found that we have: > > > > Query::=Expression > > Expression::=( OperatorExpr | IfThenElse | FLWOGR | > QuantifiedExpression ) > > > > If this specification in SQLPP is not intentionally designed, can we > change > > it to this: > > > > Query::=( Expression ) > > Expression::=( OperatorExpr | CaseExpr | QuantifiedExpression | > > SelectExpression ) ? > > > > As the Subquery are handled separately in the parenthesized > expression > > part, the "SelectExpression" here is non-subquery by default. > > > > Any thoughts? Thanks! > > > > Best, > > Xikui > > > > > >
