[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Are XPath expressions parsed using compiler parsi
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@xxxxxxxxxxxx <xsl-list-service@lists. mulberrytech.com> a C)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@xxxxxxxxx <xsl-list-service@lists. mulberrytech.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 archiveEasyUnsubscribe (by email)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|