[Monetdb-developers] XRPC syntax

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


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 at in.tum.de>
> datum: 2006/10/25 Wed PM 04:46:51 CEST
> aan: p.a.boncz at chello.nl
> cc: Ying Zhang <Y.Zhang at cwi.nl>,  P.Boncz at cwi.nl
> onderwerp: Re: Re: XRPC syntax
> 
> On Wed, Oct 25, 2006 at 03:41:44PM +0200, p.a.boncz at 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
> 





More information about the developers-list mailing list