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 datum: 2006/10/25 Wed PM 04:46:51 CEST aan: p.a.boncz@chello.nl cc: Ying Zhang , P.Boncz@cwi.nl onderwerp: Re: Re: XRPC syntax

On Wed, Oct 25, 2006 at 03:41:44PM +0200, p.a.boncz@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