[sc34wg3] Fwd: Re: TMQL: Grammar broken II

[Robert Barta]

On Mon, Feb 23, 2009 at 08:58:35PM +0100, Lars Heuer wrote:
> > On Thu, Dec 04, 2008 at 01:42:54PM +0100, Lars Heuer wrote:
> >> Found another bug in the grammar; according to "4.7 Composite Content"
> >> this is a valid TMQL expression:
> >> 
> >>      // person -- // evildoer

[...]

> ................. My e-mail wasn't very clear, sorry. Here another try.
> The entry point for all queries is
> 
>     [46]    query-expression
> 
> and [46] is defined as (abbreviated):
> 
>     select-expression | flwr-expression | path-expression
> 
> So, the parser sees "//person" and enters the "path-expression" rule
> and there is no way to accept the "--" since once you're in
> "path-expression" you cannot reach the content-rule [23].
> 
> Do I miss something?

Maybe :-)

First off, the spec says in 3.1 Syntax Conventions

   "This grammar was produced for human consumption and is not
    optimized for a particular parsing method or for a minimum of
    non-terminals."

That implies that the grammar is not LL(k) or LR(k) or LALR, or
anything. It also implies that in

   select-expression | flwr-expression | path-expression

are equal "alternatives", not necessarily "favouring"
select-expression because it is  mentioned left-most.

So this is more abstract than grammars you would have in a software
parser like ANT-the-ugly-beast-LR. Implementors have to make this
transition. Although I slowly realize that many languages do not seem
to have decent ( = simple to use) parsing packages. I was obviously
spoiled by Perl or Haskell.

--

In the concrete case

   // person -- // evildoer

is derived (this time bottom up) the following way:


            // <anchor> -- // <anchor>

[X] twice   <path-expression>   -- <path-expression>

[N] twice   <content>             -- <content>

[23]        <content>

[33]        <value-expression>

That is the end of the rope. The value-expression can be part of
something bigger, but by itself it can NEVER be a query expression.

The closest would be a as part of a tuple expression:

         ( <value-expression> )

[24]     <tuple-expression>

and _THAT_ can go all the way up:

[54]     <postfixed-expression>

[53]     <path-expression>

[64]     <query-expression>

So whoever or whatever claims that

   // person -- // evildoer

is a query expression is incorrect, but

  ( // person -- // evildoer )

is. If that is somewhere inside the TMQL spec, plz let me know.

\rho