Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/debug abssynprint.c, 1.25, 1.26 coreprint.c, 1.26, 1.27
On Tue, Oct 24, 2006 at 03:20:03PM +0000, Jens Teubner wrote:
Update of /cvsroot/monetdb/pathfinder/compiler/debug In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv19355/compiler/debug
Modified Files: abssynprint.c coreprint.c Log Message: Parser support for the `execute at' syntax extension (XRPC).
Pathfinder's parser now recognizes expressions of the kind
"execute" "at" "{" Expr "}" "{" FunctionCall "}"
Hi Jens, Would you please change the implementation of the syntax according to the discussion on the syntax? The final version (I hope:)) of the syntax should be: "execute at" Expr "xquery" FunctionCall Thanks! Jennie
where the expression in the first pair of braces specifies an URI where the function call given in the second pair should be evaluated at. Note that, in order to avoid parser conflicts, we did not directly use the syntax proposed in a recent paper submission, but rather this one that adds the curly braces.
The system will try hard to convert the expression given in the first pair of braces into a string.
An expression as shown above will lead to a Core tree situation that uses the new node kind `xrpc':
xrpc / \ URI FunctionCall
It's now Jennie's task to support that in the back-end.
I suppose the change in the syntax won't affect the structure of this node kind?
TODO: If *not* touched the code that is currently existing in Pathfinder and uses the "old" `import rpc-module' syntax. Jennie, will you rip out this old stuff, once you have implemented back-end support for the new syntax?
Yep, I will. Jennie
Index: coreprint.c =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/debug/coreprint.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -d -r1.26 -r1.27 --- coreprint.c 25 Sep 2006 11:11:36 -0000 1.26 +++ coreprint.c 24 Oct 2006 15:20:01 -0000 1.27 @@ -132,6 +132,9 @@ , [c_recursion] = "recursion" , [c_seed] = "seed"
+ /* Pathfinder extension: XRPC */ + , [c_xrpc] = "xrpc" + };
/** Current node id */
Index: abssynprint.c =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/debug/abssynprint.c,v retrieving revision 1.25 retrieving revision 1.26 diff -u -d -r1.25 -r1.26 --- abssynprint.c 25 Sep 2006 11:11:33 -0000 1.25 +++ abssynprint.c 24 Oct 2006 15:20:01 -0000 1.26 @@ -181,6 +181,9 @@ /* Pathfinder extension: recursion */ , [p_recursion] = "recursion" , [p_seed] = "seed" + + /* Pathfinder extension: XRPC */ + , [p_xrpc] = "xrpc" };
/** Names of XPath axes */
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-pf-checkins mailing list Monetdb-pf-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
Hi all, On Oct 27, 2006, 11:12 AM, Ying Zhang wrote with possible deletions:
[...] Would you please change the implementation of the syntax according to the discussion on the syntax? The final version (I hope:)) of the syntax should be:
"execute at" Expr "xquery" FunctionCall
I have not seen the discussion (why? -- has it been conducted on monetdb-developers), but I strongly vote to leave the syntax as is, i.e., use execute at { Expr } { FunctionCall } This is in line with other similar syntactic constructs in XQuery, foremost the computed document, attribute, element, text, comment constructors, the ordered/unordered specifiers, and the validate expression. Much like unordered { e } is a hint to the system to evaluate expression with lax ordering requirements, execute at { foo } { e } is an instruction to the system to evaluate e at foo. Much like for the element/attribute construtors, I also propose to admit the syntactically lighter execute at URILiteral { Expr } as an additional syntactic variant whenever the remote system URI need not be dynamically computed. Cheers, --Teggy -- | Torsten Grust | torsten.grust@gmail.com
On Fri, Oct 27, 2006 at 11:26:48AM +0200, Torsten Grust wrote:
Hi all,
On Oct 27, 2006, 11:12 AM, Ying Zhang wrote with possible deletions:
[...] Would you please change the implementation of the syntax according to the discussion on the syntax? The final version (I hope:)) of the syntax should be:
"execute at" Expr "xquery" FunctionCall
I have not seen the discussion (why? -- has it been conducted on monetdb-developers),
Obviously forgotten. I have just CC-ed the e-mail to the developers list.
but I strongly vote to leave the syntax as is, i.e., use
execute at { Expr } { FunctionCall }
This is in line with other similar syntactic constructs in XQuery, foremost the computed document, attribute, element, text, comment constructors, the ordered/unordered specifiers, and the validate expression. Much like unordered { e } is a hint to the system to evaluate expression with lax ordering requirements, execute at { foo } { e } is an instruction to the system to evaluate e at foo.
Much like for the element/attribute construtors, I also propose to admit the syntactically lighter
execute at URILiteral { Expr } ^^^^
But we only want to support FunctionCall here, instead of an arbitrary xquery expression... Jennie
as an additional syntactic variant whenever the remote system URI need not be dynamically computed.
Cheers, --Teggy -- | Torsten Grust | torsten.grust@gmail.com
[...] execute at URILiteral { Expr } ^^^^
But we only want to support FunctionCall here, instead of an arbitrary xquery expression...
Very well. So replace Expr by FunctionCall above. --Teggy -- | Torsten Grust | torsten.grust@gmail.com
participants (2)
-
Torsten Grust -
Ying Zhang