RE: [XQuery] A.1.1 Grammar Notes: parens

Fair enough. My parser doesn't work anything like the machine described
in A.2, so I've never really studied it in detail. I have a three layer
approach - layer 1 and 3 are the conventional lexer and parser, while
layer 2 builds compound terminals from primitive tokens. In that model,
layer 1 distinguishes "(" from "(:" (in fact, layer 1 swallows comments
entirely), while layer 2 combines "QName" and "(".

Michael Kay

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Michael Dyck
> Sent: 16 February 2004 19:19
> To: public-qt-comments@w3.org
> Subject: Re: [XQuery] A.1.1 Grammar Notes: parens
> 
> 
> 
> Michael Kay wrote:
> > 
> > I can't see why the note is there at all. Distinguishing 
> "(" from "(:" 
> > is no different from distinguishing "<" from "<<" or child:x from 
> > child::x.
> 
> It isn't exactly a matter of distinguishing "(" from "(:". 
> The note is there (I imagine) because, given the input
>     address (: this may be empty :)
> A.2's "longest possible match" rule forces the A.2.2 machine 
> to prefer the pattern
>     <QName "(">
> (which will lead to a lexer error) over the pattern
>     QName
> (which wouldn't). Since presumably this input should be 
> considered valid, some way had to be found to get the machine 
> to prefer the shorter pattern. I guess this extra lookahead 
> is supposed to achieve that, though exactly how it fits into 
> the operation of the machine is unclear.
> 
> (An alternative would have been to add a pattern
>     <QName "(:">
> with a transition of "EXPR_COMMENT; pushState(OPERATOR)", but:
> (a) I think you'd have to add about 17 more transitions to handle
>     similar cases, and
> (b) it would wreak havoc with the EBNF.)
> 
> -Michael Dyck
>

Received on Monday, 16 February 2004 16:11:05 UTC