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.

PATH

PATH language

PATH is conceptually like Befunge with the code being a 2D grid of characters in which execution happens in Cartesian directions. It actually has direction operators (< > ^ v) somewhat like Befunge (only conditional), but it also specifies slashes as visually intuitive reflectors (somewhat like Nick's PETSCII symbols). While Nick's program output would need to output ASCII \ / rather than PETSCII graphical characters, that and the addition of a $ would make any output execute in PATH (although it wouldn't compute anything in memory other than perform the act of tracing an execution path). I've given a few presentations that included PATH -- I'm attaching a picture that illustrates the execution order of their title-logo-program so you can see the reflectors working.

PATH language ref summary

$   Start the program here, heading right.
#   End the program.
/   Turn 90 degrees without crossing line:
     right, turn up
     down, turn left
     left, turn down
     up, turn right
\   Turn 90 degrees without crossing line:
     right, turn down
     down, turn right
     left, turn up
     up, turn left
+   Increment the current memory cell.
-   Decrement the current memory cell.
!   Jump over the next symbol.
.   Output a character from current memory.
,   Input a character from current memory.
}   Move to the next memory cell.
{   Move to the previous memory cell.
^   If current memory is not 0, turn up.
<   If current memory is not 0, turn left.
>   If current memory is not 0, turn right.
v   If current memory is not 0, turn down.