PATH and 10 Print Interpretation
From Maze
One strong thread of exploration through both the CCS workshop and the listserv was considering 10 Print output as input for another computational process: the esoteric computer language PATH.
In order to convert 10 Print output into a valid PATH program, the PETSCII characters must be replaced with ASCII back/slashes, and a single * is inserted to indicate where execution begins. This conversion is considered through various interventions -- a post-processor to modify 10 Print output, a modification to 10 Print itself, and a modification to the PATH interpreter / specification. Ultimately, the idea of 10 Print output as a genre of computational specification suggests the possibility of further software for which 10 Print is the paradigm / context -- for example, a programs written in 10-Print-PATH which themselves produce / consume 10-Print-PATH.
Exploring these approaches touches on many topics -- the definition of a maze, reimplementation, quines, visual interpretation, general computation.
Notes from the listserv
Jeremy: [W]hile the output of Nick's one-liner *visually* specifies a kind of open maze, it was not immediately intuitive to me that the information contained in the character array contains a maze. I initially imagined that data to specify a maze should requiring empty hall and full wall (low bit/high bit) which is a very different thing from this wall of slashes that might as well be ps and qs. Such an encoding strategy can't be generated with any coherency by a random function -- if you use *s and spaces with such a simple algorith, you just get static. When I thought about it, however, I realized that the twisting passages visually implied by the slashes only require a very few rules to be specified / made executable. These rules are already implemented in the esoteric language Path -- just add a $ start-point to a random location in the output, and the Path programming language will happily execute a path that navigates through the structure of / and \ characters much as we would visually or physically, ending either trapped in a loop or falling off the edge of the space. This moment where the output of one programming language becomes (even unintentionally) a new program in another language is also something I'd love to explore in the book.
