Let's do it! No issues for the rewrite step that follows when inlining, hopefully?
On Thu, Mar 15, 2018, 1:19 PM Dmitry Lychagin <[email protected]> wrote: > Xikui, > > Right, seems like we could change the FunctionDeclaration production to > include SelectExpression as you suggested. > > Thanks, > -- Dmitry > > On 3/15/18, 12:16 PM, "Xikui Wang" <[email protected]> wrote: > > 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 > > > > > > > > > > > > > >
