- developers-list - monetdb.org

[Monetdb-developers] XRPC Syntax
by Peter Boncz 28 Oct '06

28 Oct '06

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

2 1

Re: [Monetdb-developers] New serialize form of XRPC message
by Jan Rittinger 27 Oct '06

27 Oct '06

Hi Jennie, Your output looks pretty good. I would reuse as much as possible from the xml-typed mode. If you however have conflicts then I'd introduce new callbacks. In your case it seems sensible to introduce all the namespace declarations in some xrpc_serializeStart event that also prints the whole envelope tag. A xrpc_serializeStop event may then close this element. In addition you would need a new xrpc_seqStart and xrpc_seqEnd callback that uses a user-given sequence name and does not generate the namespace declarations. As you can see I proposed to introduce two new callbacks that have to be placed before/after the loop over the different iterations -- That change would be fine with me. It however requires to introduce dummy routines that have to be called for all modes except xrpc (the serializeFunStruct and its instances have to be modified -- see serialize*.mx and modules/...). What do the other think? Jan On 10/23/2006 05:32 PM, Ying Zhang wrote with possible deletions: > Hello Jan, > > With this e-mail, I would like to ask for your advice how I can > reuse/adjust the current serialization code of the "typed" mode to > support serializing the new XRPC response message. > > Maybe you have seen in our (Peter and I) XRPC paper for PLAN-X that we > have defined an XML schema for the XRPC request and response messages. > The schema definition file is avaible here: > http://monetdb.cwi.nl/XQuery/XRPC.xsd > > An XRPC response message now looks like this: > > <?xml version="1.0" encoding="utf-8"?> > <env:Envelope > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:env="http://www.w3.org/2003/05/soap-envelope" > xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope" > xmlns:xrpc="http://monetdb.cwi.nl/XQuery" > xsi:schemaLocation="http://monetdb.cwi.nl/XQuery http://monetdb.cwi.nl/XQuery/XRPC.xsd"> > <env:Body> > <xrpc:response xrpc:module="xrpcmodule" xrpc:method="test"> > > <xrpc:sequence> > <xrpc:document><a/></xrpc:document> > <xrpc:element><a/></xrpc:element> > </xrpc:sequence> > <xrpc:sequence> > <xrpc:attribute x="y"/> > <xrpc:text>z</xrpc:text> > </xrpc:sequence> > <xrpc:sequence> > <xrpc:processing-instruction>z</xrpc:processing-instruction> > <xrpc:comment></xrpc:comment> > <xrpc:atomic-value xsi:type="xs:integer">1</xrpc:atomic-value> > <xrpc:atomic-value xsi:type="xs:decimal">42.100000</xrpc:atomic-value> > <xrpc:atomic-value xsi:type="xs:string">bla</xrpc:atomic-value> > </xrpc:sequence> > > </xrpc:response> > </env:Body> > </env:Envelope> > > As you can see, the new form of XRPC response message is quite different > than the current form of the XRPC messages, but it is very similar to > the way the result of an xquery is serialized in the "typed" mode. > During the making of the new schema, we have actually consulted the > output of the "typed" mode to use the same type names, so that we can > reuse as much as possbile the code of the "typed" mode. > > The "xrpc:sequence" part is very similar to the "result:sequence" part > of the typed mode. In serialize_dflt.mx, the seriializeFunStruct-s of > "xml typed" and "xml soap" only differ in the following: > > struct serializeFunStruct struct serializeFunStruct > typed_xmlSerializeFun = { typed_xmlSerializeFun = { > "xml typed", "soap xml", > > typed_xml_seqStart, xml_seqStart, > null_complete_seqStart, xml_complete_seqStart, > typed_xml_seqEnd, xml_seqEnd, > typed_xml_seqItemStart, soap_xml_seqItemStart, > typed_xml_seqItemEnd, soap_xml_seqItemEnd, > null_seqItemSeparator soap_xml_seqItemSeparator > }; }; > > If we make two changes in the typed_* functions, all xml_* and soap_* > functions in "soap xml" can by replaced by the typed_* functions to > procude the new XRPC response messages. With these changes, we can even > get rid of the "soap" mode, and just use the "typed" mode to serialize > XRPC response messages. > > The changes I would need are the following: > > (i) instead of using the static prefix "result", use a dynamically > specified prefix, so that i.s.o. "result:sequence", "xrpc:sequence" can > be printed for XRPC response messages. Can we store the prefix in the > existing parameter XqueryCtx* ctx? Or do we need to add a new parameter > to the typed_* functions? > > This change is not _strictly_ necessary, since I can also use the prefix > "result" in the XRPC response messages, but using dynamically specified > prefixes looks nicer/cleaner to me. > > (ii) for XRPC response messages, I'd prefer to not have the namespace > definitions of "result" (or "xrpc"), "xs" and "xsi" in > <result:sequence>, because each XRPC response message can contain a > (large) number of sequences. With the NS definitions of "result", "xs" > and "xsi" included in every sequence tag is obviously wasting of > bandwidth. Do you have an idea how this change can be implemented > nicely? > > > I hope I have made my problems and ideas clear. Please ask me if it is > not so. > > Thanks in advance! > > > Regards, > > Jennie > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

2 3

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/debug abssynprint.c, 1.25, 1.26 coreprint.c, 1.26, 1.27
by Ying Zhang 27 Oct '06

27 Oct '06

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(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins

2 3

[Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

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.

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

Hi Peter, hi Jennie, On Tue, Oct 24, 2006 at 09:13:00PM +0200, Ying Zhang wrote: > I found the formal definition of XQueryD grammar (BTW. it's called > XQueryD, not DXQ. DXQ is something else.) in "A Framework for XML-Based > Integration": > > ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ] this syntax actually looks okay to me as well. The reason: XQuery is crafted in a way that it uses as few keywords as possible. To achieve that, the lexical analyzer (a) often recognizes patterns that are larger than a single word (matching "execute at" instead of "execute" removes the ambiguity with a child step searching for an `execute' element) and (b) switches parsing states depending on the symbols that the lexer sees. What we have here is that the lexical analyzer reads an expression. After reading an expression, it will *always* wait for an operator (e.g., an arithmetic operator, a sequence constructor, but also `as type', etc.). In this state it is safe to recognize a lot more keywords without making them ambiguous with, e.g., path steps. So if we throw in the `xquery' here, the state machine of the lexical analyzer should run fine again. `xquery' will be recognized as a keyword whenever an operator is expected, but not otherwise. Peter, Pathfinder's parser is strictly separated as it is supposed to be in a well-designed parser. There is a lexical analyzer, which is *independent* of the parser (done with bison in Pathfinder). Being unaware of any context information, our lexical analyzer thus cannot know that it currently is somewhere between the two components of an "execute at" clause. If you prefer the above syntax, I could implement that. It should be an easy fix. Just let me know. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 No scientist is ever right, they just can't be proved wrong at the time! -- Richard Feynman

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

Hi Peter, What is the reason that you want to avoid using the additional braces? I found the formal definition of XQueryD grammar (BTW. it's called XQueryD, not DXQ. DXQ is something else.) in "A Framework for XML-Based Integration": ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ] So they also use braces to surrond the piece of xquery query that will be executed remotely. This is similar with '{FunctionCall}'. And since Jens said that using extrax braces will make parsing easier, so I thought it won't hurt to have one more pair of braces to surround the destination expression. Jennie On Tue, Oct 24, 2006 at 08:47:48PM +0200, p.a.boncz(a)chello.nl wrote: > 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 <jens.teubner(a)in.tum.de> > > datum: 2006/10/24 Tue PM 02:55:21 MEST > > aan: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)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. > > >

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

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 <jens.teubner(a)in.tum.de> > datum: 2006/10/24 Tue PM 02:55:21 MEST > aan: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)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. >

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, To answer your opening question, this email exchange has brought us to the root of the issue, which I personally find very useful, because I like to understand what is happening to me when something is happening to me. After all, this was not really about the XRPC extension not being parsable. Rather, the small diff needed to introduce the proposed syntax does not suit your *coding* easthetics, apparently because you object to the use of REJECT in a scanner. Or something along those lines. I infer this from your qualification of my code as "lowering the quality of the Pathfinder parser". I can only assure you that "messing up the Pathfinder parser" was not my intent while writing that code. Given that the Pathfinder parser (and beyond) is mostly your brainchild, I can understand that you want to retain control over where it is heading. So if you block this proposal for reasons of taste, I will have to listen to you, even if I disagree or simply do not understand what the fuss is about (I myself care more if a language syntax is handy for a human user, rather than for a parser, which is operated by a machine without feelings). So, on to an alternative syntax. I will restrict myself to the alternatives that you find acceptable for some reason. For me the XQueryD syntax is not a holy thing, as it does not really have any installed base. It is not part of Galax, just was part of some prototype that never made it into a stable version. But I do like the 'xquery' variant better than the curly braces, plus we have indeed the argument that this is the same as something that was proposed before (even if that something has become irrelevant). So, thanks in advance for making that change.. Peter > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/25 Wed PM 06:38:03 CEST > aan: p.a.boncz(a)chello.nl > cc: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)cwi.nl > onderwerp: Re: Re: XRPC syntax > > On Wed, Oct 25, 2006 at 06:00:39PM +0200, p.a.boncz(a)chello.nl wrote: > > > Hi Jens, > > > > Well, you had me reading the flex manual there, after which I must > > still conclude that our modification is parsable. > > > > What I meant from the start is that one can match the operator > > keywords after which a "(" can legally occur (eq, etc) with preference > > over QName_LParam. See the below diff. > > > > There are also ways of doing that without REJECT, if your religion > > does not permit its use. > > e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); } > > > > The MIL parser is a mess; but gladly its internals should play no role > > in this discussion. > > Hi Peter, > > I cannot see where this shall head. Why would we, under all > circumstances, try to mess up Pathfinder's parser? As far as I can see, > *all* the proposals made by other people do use some syntax that aids > parsing. The XQuery syntax itself built its way for good reason, and > both approaches we had are very much in the flavor of XQuery. I cannot > see why we would want to give that up. > > I *strongly* vote for using either of the following two options: > > -- execute at { Expr } { FunctionCall } > > -- execute at Expr xquery FunctionCall > > Both, in my opinion, are clean and in line with the remaining language. > From a parser point of view, we could leave out the *second* pair of > curly braces, but that would only make things inconsistent. > > Also, I cannot understand why you insist on introducing your very own > syntax for XRPC. There have been other proposals. In the spirit of > interoperability, experimentation, comparison, etc. I think the adaption > of existing syntax is a good idea. It would help increasing our > system's acceptance and visibility, I argue. > > (I brought the MIL parser into the discussion, because I thought that > would put you off any attempts to lower the quality of Pathfinder's > parser.) > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Linus Torvalds is a lot like Bill Gates. Both are > about the same height. > -- USA Today >

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Wed, Oct 25, 2006 at 06:00:39PM +0200, p.a.boncz(a)chello.nl wrote: > Hi Jens, > > Well, you had me reading the flex manual there, after which I must > still conclude that our modification is parsable. > > What I meant from the start is that one can match the operator > keywords after which a "(" can legally occur (eq, etc) with preference > over QName_LParam. See the below diff. > > There are also ways of doing that without REJECT, if your religion > does not permit its use. > e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); } > > The MIL parser is a mess; but gladly its internals should play no role > in this discussion. Hi Peter, I cannot see where this shall head. Why would we, under all circumstances, try to mess up Pathfinder's parser? As far as I can see, *all* the proposals made by other people do use some syntax that aids parsing. The XQuery syntax itself built its way for good reason, and both approaches we had are very much in the flavor of XQuery. I cannot see why we would want to give that up. I *strongly* vote for using either of the following two options: -- execute at { Expr } { FunctionCall } -- execute at Expr xquery FunctionCall Both, in my opinion, are clean and in line with the remaining language. >From a parser point of view, we could leave out the *second* pair of curly braces, but that would only make things inconsistent. Also, I cannot understand why you insist on introducing your very own syntax for XRPC. There have been other proposals. In the spirit of interoperability, experimentation, comparison, etc. I think the adaption of existing syntax is a good idea. It would help increasing our system's acceptance and visibility, I argue. (I brought the MIL parser into the discussion, because I thought that would put you off any attempts to lower the quality of Pathfinder's parser.) Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Linus Torvalds is a lot like Bill Gates. Both are about the same height. -- USA Today

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, Well, you had me reading the flex manual there, after which I must still conclude that our modification is parsable. What I meant from the start is that one can match the operator keywords after which a "(" can legally occur (eq, etc) with preference over QName_LParam. See the below diff. There are also ways of doing that without REJECT, if your religion does not permit its use. e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); } The MIL parser is a mess; but gladly its internals should play no role in this discussion. Peter Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 317c317 < %option noreject --- > %option reject 607,608c607,608 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } --- > "execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); > yield (execute_at); } 651a652 > PFlog("<DEFAULT>"); 776a778,785 > {QName} { int c; > do c = input(); > while (c == 0x20 || c == 0x09 || c == 0x0d || c == 0x0a); > if (c != '(') REJECT; > gotoState (DEFAULT); > pflval.qname = extract_qname (yytext, 0); > yield (QName_LParen); > } > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/25 Wed PM 04:46:51 CEST > aan: p.a.boncz(a)chello.nl > cc: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)cwi.nl > onderwerp: Re: Re: XRPC syntax > > On Wed, Oct 25, 2006 at 03:41:44PM +0200, p.a.boncz(a)chello.nl wrote: > > > Hi Jens, > > > > Indeed you are right, I meant XQueryD. > > > > As I still do not grasp how the parsing problem manifests itself, I > > just applied the changes we desire to the parser/scanner myself (see > > below). As far as I can see, this works. The parser reports one more > > shift/reduce conflict in state 122 (it now has 3 conflicts instead of > > 2, and in total there are 17 instead of 16), which on my fiirst sight > > does not seem significant. > > 42 eq (42) > > This is quite precisely the problem I tried to describe. Trust me, > parsing XQuery is a lot trickier than MIL. (And even that you > implemented as simple as possible; think about operator priorities.) > > > Your characterization of XQuery as a language with little keywords, > > makes me appreciate our current syntactical proposal more than a > > solution with braces or keywords. If forced to choose between them, I > > would go for a keyword. In that case, i would not use "xquery" as this > > might put the XQueryD guys into trouble (they want a valid XQuery > > after that - we just a function call), but rather propose "function", > > i.e. execute at "foo" function bla(1). > > I'd actually use the same argument the other way round. Using the same > syntax as somebody else leaves us room for (maybe) supporting arbitrary > XQuery expressions at some point in time. In both, the "curly braces" > approach, as well as in the "keyword" approach we could, if needed, > easily open our parser to allow any expression. > > Regards, > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Beware of bugs in the above code; > I have only proved it correct, not tried it. > -- Donald Knuth >

1 0