Hi Gunther, Thanks for your comprehensive feedback!
> - when I ran some tests with BaseX, my impression was that tail call > optimization can be achieved for p:transition. Not sure, though. Out of interest, I checked our query plan (using -x on command-line). As you already guessed, p:transition is tail-call optimized, as well as p:transition, p:matchW and p:token (and various other functions), no matter if return types are used or not. > - to be honest, I am not convinced that XQuery is the ideal language > for coding parsers. I was just exploring whether it could be done, > when I started on this, and I found that once you have a parse > tree in XDM, you can do a lot of interesting tasks on it. Yes, it works very well, and it’s interesting to see how many people use it for all kinds of things. In practice, it’s mostly the parsing time that takes time, so I hope we’ll soon manage to keep pre-compiled XQuery modules in main-memory. We are working on that. > - if anybody was interested, I could generate Java (or other) > extension functions for some XQuery processor, like I do for Saxon. This sounds interesting indeed! Could you provide us with a link to the Saxon extension functions? > That would combine high performance with ease of use. I would love > to see Adam Retter's proposal for portable Expath extension > functions > ( > http://www.adamretter.org.uk/presentations/implementation-of-portable-expath-extensions_xml-london_20150607.pdf > ) > go forward. Me too. I’m just not sure how much time it would cost us to make it happen. I’ll put it on my mental queue… > Sorry for any inconvenience that this may have caused. No reason to be sorry. Issue like that are a perfect chance to further improve our processor. Christian
