Hi Jens, I had missed this email. The ambiguity you identify is for operators, which by default are built-ins. Thus, technically there is no ambiguity. In this case, you would parse "x eq y" as an ExprSingle, and then you will actually give a parse error because of the missing function application. If it is really impossible to do (for some reason), I would propose the syntax: XRPCCall ::= "execute" "at" ExprSingle "function" FunctionCall which is analogous to DXQ: "execute" "at" ExprSingle "xquery" ExprSingle Peter

van: Jens Teubner datum: 2006/10/24 Tue PM 02:55:21 MEST aan: Ying Zhang , P.Boncz@cwi.nl onderwerp: XRPC syntax

Hi Jennie, hi Peter,

I am currently looking into the XRPC syntax. Primarily I wanted to give you feedback to what you wrote in your Plan-X submission.

So you are defining the syntax to be

XRPCCall ::= "execute" "at" URILiteral FunctionCall

Lateron, however, you allow more than just a literal URI, but rather an XQuery expression. So `URILiteral' is definitely wrong here.

Once you changed this to, say, ExprSingle, you end up with ambiguity in your parser. Consider

execute at "foo" eq ("bar")

(I couldn't think of a better example ad hoc.) What we have here is an ambiguity: we don't know whether `eq' is supposed to be a function call, or if it is the binary operator `eq', followed by another expression in parenthesis.

So I will take the freedom to modify your syntax proposal and do it in a more XQuery-like style:

"execute" "at" "{" Expr "}" "{" FunctionCall "}"

This avoids the ambiguity and should make it rather easy to parse.

...already hacking...

Jens

-- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263

Time is money. Especially if you make clocks.