Dagaz: About XSLT Again

Earlier, I wrote a short article on XSLT programming , but it was somewhat synthetic, educational in 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 its use are kind of boring and not very interesting. More recently, I found a more fun use for this language. It’s about this, as well as about “how I got to such a thought” that I’m going to tell. 

For some very long time now, I have been literally 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 drawbacks (besides the " fatal " one). However, the advantages of these developments are noticeably greater and almost the main thing is the declarative nature of the descriptions used. Here, for example, looks like a description of the game in GDL :

(game Tic-Tac-Toe
   (board
      (tiling square)
      (size33)
   )
   (win (in-a-row3))
)

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


For all its declarativeness, such a description requires a parser and this is exactly the task that I am currently working on. As in Lisp , there is almost no syntactic sugar in this language. The task of parsing the source text into tokens is trivial , but what to do next? Obviously, some kind of internal representation is required, providing convenient access to descriptions of objects such as a board and figures.

I thought about this question for a long time, until I realized that I was going to develop a simplified XPath analogue.. An attempt to develop such a "bicycle" is certainly a "wake-up call". In fact, if you needed something that behaves like XPath, why not use it? All you need is to convert the data to XML , for example as follows:


The parser that forms this representation is slightly less trivial than the scanner considered earlier (in fact, it’s even simpler if you do not consider the include implementation ). Its task is to form a stream of SAX events, in the order of receipt of the corresponding tokens at the input. After receiving the DOM representation, the navigation task, 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 code, you can see lines like “ decrement! ”, “ Is-empty? ” Or “ > = ” and these are clearly not the “identifiers” that can be placed in the names of XML tags. After some thought, I decided to place them in the attributes, as follows:


Of course, such a record is much less intuitive, but it is not intended for humans! How to get this form? You can rewrite the parser ... But there is a simpler 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, changes in the source code of the parser would look much less obvious). Downloading from SAX to the DOM along with the transformation being performed does not differ much 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 ". Why might additional conversions be needed? Yes for anything! In ZRF, for exampleThere is a wonderful opportunity. One file can contain descriptions of several similar games at once, differing only in details. There is one main description of " game " and several " variant " inheriting it :


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

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

Next, just remove the duplicates:

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

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

You can create even more sophisticated weapons to combat 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 keyworddefines, in fact, a macro that can be embedded absolutely anywhere in the description. Sometimes it is very convenient and saves from a lot of writing. In ZRF macros, you can use the parameters $ 1 , $ 2 , etc. We will do better! Our parameters will have normal names:

(macro (plus a b)
  (+ a b)
)
(plus (*23) (*56))

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

(+ (*23) (*56))

Of course, the macro itself and its arguments can be much more complex. In the body of a macro, nested macros can be called. It is not yet possible to implement a recursive macro call, but only because of the lack of a recursion stop mechanism. So far I have not found a single practical example of the use of recursive macros and embedding the ability to perform arithmetic calculations in a transformation will only complicate it, without the need.

XSLT can also be used for more complex source code transformations. The transformations that transform the description of the game in GDL or ZRF into the Dagaz source code should be complicated, but there is nothing fantastic about them. If desired, even PREZRF macros can be implemented .(however, I think that this is already superfluous). Thus, XSLT will provide backward compatibility, without the need for direct processing of legacy (from the point of view of Dagaz ) 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 full Forth machine to be implemented in the XSLT transformation .