are there no looping constructs or decisions
until now the “language” of the CRMT (CloneRotateMirrorTranslate) approach has 6 elements. Perhaps this could some day grow to a “Pattern Description Language” that includes the usual control structures.
I guess that has to be periodic tiling only (i.e. penrose would require an increasingly long list)?
It makes no difference if a command list describes 60 proto-tiles of a periodic or non-periodic tile. The restriction is RAM because image proto-tiles should have an interesting internal texture. I am using as standard t_w = 1000 so if there is a complex tiling type like islamic patterns then moving 60 proto-tiles over a background would have serious RAM requirements.
The economic idea of periodic tiling is to make a rectangle tile from possibly non-rectangle proto-tiles and then make an arbitrary large pattern by making a n x m array of the tile (translation vector (1 1)). Or to make a non-rectangle basic cell from the proto-tiles like a hexagon in the p3m1 case and then use a more complex translation vector to distribute such hexagons. Such strategies are not working with non-periodic image tilings where any pattern detail must always be constructed by moving the proto-tiles.
this is possibly more interesting than you make it appear!
I do not know how this could possibly be make more interesting than by linking to the incredible aesthetic result pictures as motivation for developers and list writers. And the writers have also the motivation of sustainability because command lists can generate images even decades later independent of any actual interpreter implementation.
Or is the intent for that never to be used directly and only as a backend?
yes a user don’t have to get in contact with the content of the command list and the coordinate list. In my prototype this two files were selected by giving their paths and the program is doing the string and image processing.