[Monetdb-developers] XRPC syntax

p.a.boncz at chello.nl p.a.boncz at chello.nl
Fri Oct 27 12:39:01 CEST 2006

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.

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).


Index: parser.y
RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v
retrieving revision 1.47
diff -r1.47 parser.y
< %token execute_at_lbrace               "execute at {"
> %token execute_at                      "execute at"
< XRPCCall                  : "execute at {" Expr "}" "{" FunctionCall "}"
<                             { $$ = wire2 (p_xrpc, @$, $2, $5); }
> XRPCCall                  : "execute at" Expr FunctionCall
>                             { $$ = wire2 (p_xrpc, @$, $2, $3); }
Index: scanner.l
RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v
retrieving revision 1.40
diff -r1.40 scanner.l
< "execute"{_}"at"{_}?"{"            { pushState (OPERATOR); pushState (DEFAULT);
<                                      yield (execute_at_lbrace); }
> "execute"{_}"at"{_}?               { pushState (OPERATOR); pushState (DEFAULT);
>                                      yield (execute_at); }
> {QName}{_}?"("/[^:]                { gotoState (DEFAULT);
>                                      pflval.qname = extract_qname (yytext, 0);
>                                      yield (QName_LParen);
>                                    }

> van: Jens Teubner <jens.teubner at in.tum.de>
> datum: 2006/10/25 Wed AM 11:28:53 CEST
> aan: Ying Zhang <Y.Zhang at cwi.nl>
> cc: p.a.boncz at chello.nl,  P.Boncz at cwi.nl
> onderwerp: Re: XRPC syntax
> 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

More information about the developers-list mailing list