Dagaz: Again about XSLT

Earlier, I wrote a small article about programming on XSLT , but it was of a somewhat synthetic, educational nature. In fact, if someone suddenly needs to find one of the possible arrangements of “8 queens,” there are a dozen other, more convenient, languages ​​than XSLT to solve this problem. I often use XSLT in my work, but these examples of using it are boring and not very interesting. Most recently, I found a more amusing application for this language. It is about this, as well as about “how I have come to this thought,” I am going to tell you.

For quite some time, I have literally been obsessed with the idea of ​​creating a universal “engine” designed to develop abstract logic games (such as Checkers , Chess or Go ). Of course, I'm not original. Similar projects exist , but all of them, in my opinion, have shortcomings (besides the " fatal "). However, the advantages of these developments are much greater, and perhaps the main thing is the declarative nature of the descriptions used. So, for example, the description of the game in GDL language looks like:

(game Tic-Tac-Toe (board (tiling square) (size 3 3) ) (win (in-a-row 3)) ) 

Such a record is compact and self-sufficient. It can be used as a “raw material” for the work of genetic algorithms that develop new types of logic games. Unlike the Ludi project, I do not set myself such a goal, but a compact description will not be superfluous for me. So, today, the description of one of the famous games in my repository looks like:


With all its declarativeness, such a description requires a parser and this is exactly the task that I currently do. As in Lisp , there is practically no “syntactic sugar” in this language. The task of parsing the source text into lexemes is trivial , but what to do next? Obviously, some kind of internal representation is required, providing convenient access to descriptions of such objects as a board and figures.
')
I thought about this question for a long time, until I caught myself thinking that I was going to develop a simplified analogue of XPath . An attempt to develop such a "bicycle" is certainly a "disturbing bell." In fact, if you need something that behaves like an XPath, why not use it? Just convert the data to XML , for example as follows:


The parser that forms such a representation is a bit less trivial than the scanner discussed earlier (in fact, it is even simpler if you do not consider the include implementation). His task is to form a stream of SAX events, in the order in which the corresponding tokens arrive at the input. After receiving the DOM representation, the task of navigation, according to the loaded description, is solved elementarily . But there is one “but”: for more convenient work, it is desirable to have an XML description in a slightly different format:


Here, life makes its own adjustments. In the above source, I can see such strings as " decrement! ", " Is-empty? " Or " > = " and these are clearly not the "identifiers" that can be placed in the names of XML tags. After some reflection, I decided to place them in attributes, as follows:


Of course, such a record is far less intuitive, but it’s not intended for humans! How to get this form? You can rewrite the parser ... But there is an easier way! XSLT is designed to convert XML from one form to another. We use it . You can see that this is a very simple conversion (in any case, the changes in the source code of the parser would look much less obvious). Loading from SAX to DOM with the transformation in progress is not much different from the same loading without it.

Appetite comes with eating. Where there is one transformation, you can perform several. Simply combine them into a " conveyor ". What may need additional conversions? Yes, for anything! In ZRF, for example , there is a great opportunity. One file can contain descriptions of several similar games at once, differing only in details. At the same time there is one main description of " game " and several inheriting its " variant ":


It is required to describe only those objects that have changed. The rest will be inherited from the only one in the game tag file. Here is the transformation that realizes this “magic.” The idea of ​​conversion is simple. Opening another variant , we create a variable containing both subtags of both the variant tag itself and the corresponding game tag (the order of the subtags does not matter):

 <xsl:variable name="u"> <xsl:copy-of select="n"/> <xsl:copy-of select="/r/n[*[position()=1 and name()='a']='game']/n"/> </xsl:variable> 

Then just remove duplicates:

 <xsl:for-each select="exsl:node-set($u)/n"> <xsl:variable name="pos" select="position()"/> <xsl:if test="$pos=1 or not(*[position()=1 and name()='a'] = preceding-sibling::n/*[position()=1 and name()='a'])"> <xsl:copy-of select="."/> </xsl:if> </xsl:for-each> 

The only thing to be remembered here is that, according to the XSLT 1.0 specification, the “fragment of the result tree” stored in a variable cannot be used directly (except for trivial use cases in the copy-of ). You must use the node-set extension function to convert it to a set of nodes.

You can create and even more sophisticated weapons to fight against "copy-paste". This transformation is more complicated. I managed to implement it correctly only on the third attempt, but the result was worth it. The fact is that in ZRF, the define keyword defines, in essence, a macro that can be embedded absolutely anywhere in the description. Sometimes it is very convenient and saves from a large amount of writings. In ZRF macros, you can use the parameters $ 1 , $ 2 , etc. We will do better! Our parameters will have normal names:

 (macro (plus ab) (+ ab) ) (plus (* 2 3) (* 5 6)) 

After performing the macro.xsl conversion, in the source code we get the following:

 (+ (* 2 3) (* 5 6)) 

Of course, the macro itself and its arguments can be much more complex. In the body of the macro, it is allowed to call nested macros. While it is impossible to implement a recursive macro call, but only because there is no mechanism for stopping recursion. So far, I have not found a single practical example of using recursive macros and embedding the ability to perform arithmetic calculations in a transformation will only complicate it, unnecessarily.

XSLT can also be applied to more complex source code conversions. The transformations that transform the description of the game in GDL or ZRF into the source code of Dagaz should be complicated, but there is nothing fantastic in them. If you wish, you can even implement PREZRF macros (however, I think that this is already superfluous). Thus, XSLT will provide backward compatibility without the need to directly process legacy (from the Dagaz point of view) formats. It will not be possible to provide only support for the Axiom description format, but only for the reason that this would require the implementation of a full Forth machine in the XSLT transformation.