Re: [xsl] Re: FXPath - A comment on EXSL

Subject: Re: [xsl] Re: FXPath - A comment on EXSL
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Thu, 1 Mar 2001 13:41:24 +0000
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

> 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.


   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'?


Jeni Tennison

 XSL-List info and archive:

Current Thread