Dear all,
I know you don't probably want to see any more emails on this, but I will re- visit the proposed XRPC syntax once more.
The following proposals have been made: (a) "execute at" SimpleExrp FunctionCall (in the paper) (b) "execute at" "{" SimpleExpr "}" "{" FunctionCall "}" (currently implemented) (c) "execute at" "{" SimpleExpr "}" FunctionCall (lighter variant) (d) "execute at" SimpleExpr "xquery" FunctionCall (XQueryD.1) (e) "execute at" SimpleExpr "function" FunctionCall (XQueryD.2)
I will first try to summarize the positions on these proposals: - Jens: stresses the point that lexical analysis should be easy. Secondary, he values a connection with XQueryD, with preference for full query support (not only module function calls). Jens supports (b), (c) and (d). - Jennie: seems not to care about the exact syntax. Tis may be a ery wise position. - Torsten: prefers parentheses notation, to denote a lexical scope with special semantics (similar to element and attribute). Supports (b) and (c). - Peter: is rapidly progressing to a point not to care, but under interrogation will still confess to a preference for (a).
Is this an interrogation??
Yes, yes, I will confess:
As XQueryD is "dead" in the sense that it is not even in Galax where it was proposed, I do not feel inclined to adapt all of the syntax necessarily (we do adopt "execute at" in any case, so they can be happy with that). The XQueryD proposal requires quite a bit of analysis and transformation to correctly parse a query with some variables appearing without being defined, in the free-form xqueries they support. This is not required when viewing an RPC as a remote *function* call, such that the XQuery language support for function signatures can be leveraged to make parameters explicit. Then, for the user the simplest syntax for RPC is (a), at least in the sense that it is the shortest.
Suppose we *do* view XRPC as an extension of XQueryD (I actually don't), or really a special case within it, as Jens says. Because free-format xqueries need extra implementation effort (parameter extraction) and a protocol extension (to send the query definition), and cannot benefit from pre- processing and a function cache (easily) we can and want to use a faster execution strategy for the specific (XRC) case of module function calls (i.e. optimized to fit into the function cache -- this saves a lot of latency, from 170msec to 35msec) . To aid this decision, syntax support can be given (i.e. using the keyword "function" instead of "xquery"). Also, with two different keywords, systems could support both functions and free-form, or any of the two. Therefore, if asked for my preference after (a), I would favor (e) over (d). But once again, I actually do not feel much about the need to be XQueryD consistent.
Now Torsten's opinion is that when it is necessary to delimit the thing being RPC-ed, then parentheses may be the most logical delimiters. This then goes counter to the XQueryD proposal, which uses "xquery". His well-formulated argument then made me start doubting my second-best preference (e); maybe (b) is after all more logical. Still, it does not make me doubt about my first preference, (a).
\Is explicit delimiting necessary, for an extension that does not build on XQueryD, and only has the ambition to call single XQuery functions remotely, in any case? I'd say no.
What remain are Jens' reserves about (a) being possible/attractive in the scanner/parser. I can come up with the below short diff. Unless previous versions, this one works, and abides to the spirit of the scanner that refrains from using input()/unput() nor REJECT.
When in operator mode, the scanner should not see a QName followed by a parenthesis, unless it is a builtin operator name (e.g. "x" eq ("y")), so QName- s were not allowed. In case of XRPC style (a), this is what happens when finishing the parse of the URI expression( e.g. execute at "x" fcn("y")). My modification addes a rule with lowest preference in the OPERATOR mode to accept a QName (lowest pref, so it was not recognized as a builtin operator), and then matches the '(' in a new more EXPRFCNCALL mode that serves just that purpose.
Peter
Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 136a137
|| YY_START == EXPRFCNCALL \
343a345
/* 25 EXPRFCNCALL */
368a371
%x EXPRFCNCALL
607,608c610,611 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } ---
"execute"{_}"at"{_}? { pushState (OPERATOR); pushState
(DEFAULT);
yield (execute_at); }
776a780,787
{QName} { gotoState (EXPRFCNCALL); pflval.qname = extract_qname (yytext,
0); }
. { yield (invalid_character); } }
<EXPRFCNCALL>{ {_}?"("/[^:] { gotoState (DEFAULT); yield (QName_LParen); }
Index: parser.y =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v retrieving revision 1.47 diff -r1.47 parser.y 353c353 < %token execute_at_lbrace "execute at {" ---
%token execute_at "execute at"
2766,2767c2766,2767 < XRPCCall : "execute at {" Expr "}" "{" FunctionCall "}" < { $$ = wire2 (p_xrpc, @$, $2, $5); } ---
XRPCCall : "execute at" Expr FunctionCall { $$ = wire2 (p_xrpc, @$, $2, $3); }