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