Re: [xsl] Are XPath expressions parsed using compiler parsingtechniques?

Hi Roger,

The second version of Fleur, my own XQuery engine written in _javascript_, is also including its own handwritten parser. This one is a _javascript_ port from the XSLT stylesheet of old XSLTForms versions which parsed XPath expressions into _javascript_ instructions. It can be tricky for a homemade parser to consider, first, "if" as an element name, then, "if(a eq b)" as a function call, then "if(a eq b) then" as the beginning of an If-then-else statement, because "if" is not a keyword.

About errors detection, it is quite helpful for developers to locate each error within the corresponding source text. This location collect has to be implemented within the parser.

Static errors are to be detected at parser/compiler step. Some are grammatical errors and parsing will detect them. Others are due to type errors: after parsing, some kind of evaluation has to be performed not with values but with types (sequence types, actually), and sometimes union of types, to avoid most type checks at runtime. It is also surely possible to evaluate static expressions, such as 3 + 5, and to normalize values, such as 7.00. For optimising the compiler output, it is interesting to consider that atomization is useless on atoms. For runtime, considering position predicates, such as [1], is a common optimisation.

Dynamic errors handling requires links to source within the result of the parser/compiler. It is also required for a step debugger.

--Alain

Le 10/05/2022 00:42, Michael Kay mike(_at_)saxonica(_dot_)com <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> a écrit :

The XPath parser used in Saxon is a hand-written hybrid of a recursive-descent parser and a precedence parser.

The very first version was actually derived from James Clark's xt parser, and over the years it evolved out of all recognition, but without ever being redesigned from scratch. I have no idea if throwing it away and starting again with a generated parser would give any benefits. I suspec that having a hand-written parser gives us more control over diagnostics and error recovery, and it also enables us to support multiple grammars (different versions of XPath and XQuery, plus XSLT patterns) within a single parsing framework.

XPath (and even more so XQuery) has a lot of ad-hoc rules for resolving ambiguities, for example the rule that in the _expression_ (/ or /*), "or" parses as an element name, not as a binary operator (I don't think this ambiguity was even discovered for many years after XPath 1.0 was published). Again, I think it's probably easier to implement such ad-hoc rules with a hand-written parser. But someone who understands a particular parser generator well could probably find a way to do it.

Michael Kay

Saxonica

On 9 May 2022, at 21:35, Roger L Costello costello(_at_)mitre(_dot_)org <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

Roger wrote:

>> Are XPath expressions parsed using

>> compiler parsing algorithms?

Michael Kay responded:

Yes, of course

Hi Michael, does that mean each time Saxon encounters a place in an XSLT program where an XPath _expression_ is expected, Saxon sends the _expression_ into an XPath parser which tokenizes the _expression_, parses it into a syntax tree, and then traverses the tree to evaluate the _expression_? Did you use a parser generator to auto-generate the parser? If yes, which parser generator did you use? If you didn't use a parser generator, why not?

/Roger

XSL-List info and archive

EasyUnsubscribe (by email)