30017 2016-11-20 15:39:08 +0000 UpdatingFunctionCall use of PrimaryExpr makes the grammar ambiguous. 2017-01-10 17:30:56 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Update 3.0 Last Call drafts PC Linux RESOLVED WORKSFORME P2 major --- 1 msclrhd john.snelson jmdyck public-qt-comments oldest_to_newest 128235 0 msclrhd 2016-11-20 15:39:08 +0000 UpdatingFunctionCall is defined in Update Facility 3.0 as: [207] UpdatingFunctionCall ::= "invoke" "updating" PrimaryExpr "(" (ExprSingle ("," ExprSingle)*)? ")" However, PrimaryExpr contains FunctionCall. This means that for: invoke updating test() 'test()' will be interpreted as FunctionCall. That is: UpdatingFunctionCall: 'invoke updating' PrimaryExpr/FunctionCall: 'test()' [error]: missing token '(' It also does not make sense for this to be an OrderedExpr or Constructor (which are valid according to the grammar). It would make more sense to define this similar to the XQuery 3.1 ArrowFunctionSpecifier: [127] ArrowFunctionSpecifier ::= EQName | VarRef | ParenthesizedExpr For example: UpdatingFunctionCall ::= "invoke" "updating" UpdatingFunctionCallSpecifier "(" (ExprSingle ("," ExprSingle)*)? ")" UpdatingFunctionCallSpecifier ::= EQName | VarRef | ParenthesizedExpr 128238 1 jmdyck 2016-11-21 03:46:23 +0000 (In reply to Reece H. Dunn from comment #0) > UpdatingFunctionCall is defined in Update Facility 3.0 as: > > [207] UpdatingFunctionCall ::= "invoke" "updating" PrimaryExpr "(" > (ExprSingle ("," ExprSingle)*)? ")" > > However, PrimaryExpr contains FunctionCall. This means that for: > > invoke updating test() > > 'test()' will be interpreted as FunctionCall. That is: > > UpdatingFunctionCall: 'invoke updating' > PrimaryExpr/FunctionCall: 'test()' > [error]: missing token '(' Yes, that looks like the correct behaviour to me. What do you think is ambiguous? > It also does not make sense for this to be an OrderedExpr or Constructor > (which are valid according to the grammar). (Note to others: "this" = "the PrimaryExpr of an UpdatingFunctionCall".) E.g., if you used a Constructor there, you'd get a type error. But it's not the grammar's job to only derive type-safe queries. > It would make more sense to define this similar to the XQuery 3.1 > ArrowFunctionSpecifier: > > [127] ArrowFunctionSpecifier ::= EQName | VarRef | ParenthesizedExpr > > For example: > > UpdatingFunctionCall ::= "invoke" "updating" > UpdatingFunctionCallSpecifier "(" (ExprSingle ("," ExprSingle)*)? ")" > UpdatingFunctionCallSpecifier ::= EQName | VarRef | ParenthesizedExpr It's possible that might make more sense to some people. But note that UpdatingFunctionCall is fairly explicitly modelled after XQuery's DynamicFunctionCall, which also uses a PrimaryExpr to specify the function to be invoked. 128239 2 msclrhd 2016-11-21 07:11:40 +0000 (In reply to Michael Dyck from comment #1) > (In reply to Reece H. Dunn from comment #0) > > It would make more sense to define this similar to the XQuery 3.1 > > ArrowFunctionSpecifier: > > > > [127] ArrowFunctionSpecifier ::= EQName | VarRef | ParenthesizedExpr > > > > For example: > > > > UpdatingFunctionCall ::= "invoke" "updating" > > UpdatingFunctionCallSpecifier "(" (ExprSingle ("," ExprSingle)*)? ")" > > UpdatingFunctionCallSpecifier ::= EQName | VarRef | ParenthesizedExpr > > It's possible that might make more sense to some people. But note that > UpdatingFunctionCall is fairly explicitly modelled after XQuery's > DynamicFunctionCall, which also uses a PrimaryExpr to specify the function > to be invoked. Thanks for the clarification. I was thinking of things like: invoke updating fn:put(...) However, if I understand correctly, the 'invoke updating' here is not needed as fn:put has the updating annotation (and any other updating function). Likewise, it would be an error to use `$f(...)` if `$f` references an updating function -- 'invoke updating' should be used here -- and `invoke updating $f(...)` would be an error if `$f` does not reference an updating function. 128250 3 jmdyck 2016-11-21 20:24:26 +0000 (In reply to Reece H. Dunn from comment #2) > > Thanks for the clarification. I was thinking of things like: > > invoke updating fn:put(...) > > However, if I understand correctly, the 'invoke updating' here is not needed > as fn:put has the updating annotation (and any other updating function). Right, a FunctionCall can reference a simple function or updating function, making it a simple expression or updating expression respectively. > Likewise, it would be an error to use `$f(...)` if `$f` references an > updating function -- 'invoke updating' should be used here -- That true if none of the args is "?": "If the function returned by the PrimaryExpr [of a dynamic function invocation] is an updating function, and the dynamic function invocation is not a partial function application, a dynamic error is raised [err:XUDY0038]." > and `invoke updating $f(...)` would be an error if `$f` does not > reference an updating function. No, a dynamic updating function call "can invoke either an updating function or a simple function". 128353 4 jmdyck 2017-01-10 17:30:56 +0000 The Working Group decided today to close this bug as "Works For Me". Please reopen if there are unresolved matters.