(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.

(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.

(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".

The Working Group decided today to close this bug as "Works For Me".
Please reopen if there are unresolved matters.