I found only one attempt to create such compiler - http://sourceforge.net/projects/xsltc/. But this project is dead for decade already. Are there any other examples? Opensource or commercial?
Are there any fundamental technical difficulties with building such software? With the whole approach of compiling XSLT natively?
I suppose there are good use cases for using it - places where we don't need to change XSLT but still would like to get higher performance (and probably, lower memory requirements).
Are there any other reasons this software may be not so efficient as it looks? - Are interpreting XSLT processors as efficient as compiled would probably be?
From my understanding, XSLT isn't very popular anymore. Generally, it's easier and more powerful to use your favorite XML library for your language of choice, parse your XML data, and write code to format the output the way you want it.
On the other hand, it seems like you have had some success with it already. There are cases when it's useful. Check this SO question out for more details on the pros and cons of XSLT.
Anyway, software developers in general aren't big fans of XSLT, which would explain why there hasn't been a big movement to write an optimized XSLT parser in C++.
Dr. Michael Kay just announced Saxon/C http://www.saxonica.com/saxon-c/index.xml
From the home page of the product:
Saxon/C is an alpha release of Saxon-HE on the C/C++ programming platform. APIs are offered currently to run XSLT 2.0 from C/C++ or PHP applications.
License
The product is open-source. The primary license is the Mozilla Public License version 2.0. In most cases, the source files are marked as being "incompatible with secondary licenses", which means that the code cannot be combined with code issued under a GPL license (the reason for this is the difficulty of contacting all past contributors to gain their assent.)
Some components are licensed under the Apache version 2.0 license or under BSD-style licenses. For more information on licensing, see license
Download
Please click on the link below to download the Saxon-C installer.
libsaxon-HEC-setup.zip (30 MB)
XSLT is a functional langauge with some pattern matching.
You could arguably compile it as a set of pattern-directed rules, with metamatching make sure that all patterns applicable at an instant were handled efficiently.
Compiling pattern-directed rules langauges is pretty well understood; see work on Charles Forty's Rete networks in the early 80s and derivatives over the past twenty years.
So if somebody wanted to do this, they could. Where's the economic incentive?
If you did want to do this, you want a tool that can process XSLT as a set of patterns rather than using an XML processor to treat it asdumb XML document at it otherwise appears to be. And you'd want to be able to manipulate/compose the patterns and generate target machine code. You'd need a tool that is designed to manipulate symbolic structures.
LISP would be good, but isn't particularly good are parsing XML (fixable with sweat), and isn't particularly good at manipulating generated C++ code (fixable only with a vast amount of sweat so unlikely).
Our DMS Software Reengineering Toolkit is a system designed to treat formal documents as parts in essentially the same way a compiler treats source code as a set of langauge structures. It has XML parsers, and can manipulate C++ code fragments in parts, in composition, and can optimize the result by applying C++ optimization source-to-source program transformation rules. (Vast amount of sweat already invested in the C++ manipulation).
We've done pattern-directed rule compilers using DMS, not for XSLT, but rather to compile those source-to-source program transformation rules, by meta-matching the patterns and tracking the state of induced changes. You get really big automata (sort of the same way LR parsing tables get big) that can implement the translation.
Haven't done this for XSLT, though.
