Hi David,

> As the FXPath grammar is written, IfExpr has higher precedence than
> AndExpr so it will be parsed as
>
> if (and) then (*) else (- 2)

I'm no parser writer, but when you said:

> If I've not overlooked something, the FXPath grammar can be parsed
> with a single token lookahead. This is what's currently needed for
> XPath 1.0.

I thought that single token lookahead had something to do with only
needing to look ahead a single token to be able to work out what a
token means. Perhaps my naivety is showing through, but in your
example:

> or and and or and or or and or

then you *know* that the first 'or' must be an element name because if
it were an operator name then it would have something in front of it,
so you *know* that the first 'and' has to be an operator name, so you
*know* that the second 'and' has to be an element name and so on. So
you can tokenise it all successfully before working out what kind of
expression has priority.

With:

   if and then * else - 2

then you look at the first 'if' and all you know is it could be an
element name or the 'if' keyword. So you look ahead a single token,
and see the 'and', but this doesn't help - the 'and' could be an
element name (in which case the 'if' is a keyword) or it could be an
operator (in which case the 'if' is an element name).

In fact you have to tokenise the entire expression before you choose
to interpret the 'if' as a keyword because the if expression has a
higher priority than the and expression.  Before then, you don't know
whether it's going to work out to be:

  if and then * else        (can only be an and expression)
  if and then * else or     (can only be an if expression)
  if and then * else or foo (can only be an or expression)

Perhaps I've misinterpreted the term 'single token lookahead'?
  
Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list