[Monetdb-developers] XRPC Syntax

28 Oct 2006

      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); }

Peter Boncz

Ying Zhang

tags

participants (2)