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). Peter 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); } Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 607,608c607,608 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); }

"execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); yield (execute_at); } 776a777,780 {QName}{_}?"("/[^:] { gotoState (DEFAULT); pflval.qname = extract_qname (yytext, 0); yield (QName_LParen); }

van: Jens Teubner datum: 2006/10/25 Wed AM 11:28:53 CEST aan: Ying Zhang cc: p.a.boncz@chello.nl, P.Boncz@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