PATH and 10 Print Interpretation

From Maze

One strong thread of exploration through both the CCS workshop thread and the 10-print listserv has been 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.

Contents [hide] 1 PATH 1.1 PATH language ref summary 2 10 Print output as PATH 3 10 Print reimplemented in PATH 4 Discussion 5 PATH Prime

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-execution.png
726 × 323 pixels

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.

10 Print output as PATH

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.

10 Print reimplemented in PATH

Michael: ...I have perversely implemented 10 print in path. I've attached the path source in both uncommented and commented form. There's no cool ascii art double coding in my program - it's unvarnished path code. The file maze.txt contains generated output. Some observations:

1. In the same way that Ian argued 10 print is more native in basic than in assembly, I think I've conclusively shown it is also not a native path program.
2. My path program generates labyrinths by endlessly walking a labyrinth (perhaps countering the first point).
3. Looking at 10 print in 6502 assembly still masks the complexity of 10 print, particularly the random number generator - compare the 5 instruction 6502 implementation of the 8 bit LFSR with the path implementation. Working in a turing minimalist language with unary arithmetic highlights the tower of abstraction on top of which a von Neumann architecture sits.
4. Staring at the LFSR code in path (and even assembly) fills me with wonder as to how that chunk of code successfully stands in for "making an aesthetic decision."

Discussion

Michael: "The output of 10 print is a path program."

Ian: Except not really, because the output of 10 print is NOT / and \ but PETSCII characters that look similar to those but which are different. Just sayin.

Nick: Right, but as I noted earlier, it's a Path program where

Path' [Path-prime]

is a modified version of Path that prepends $ to a program automatically before

processing it and uses PETSCII 109 and 110 instead of / and \.

Jeremy: A succinct recap: 10 print outputs executable

Path'

programs, whose operations are a kind of performance of the maze-like wandering that we see implicit in 10 print. This is one response to the argument that 10 print does not informatically specify a maze-like texture, with a demonstration being that replacing the PETSCII characters with Ps and Qs, causing our perception of it to suddenly change.

Path'

retorts that it threads the labyrinth of Ps and Qs all the same. What I love about Michael's Path version of 10 print is that it closes the loop -- it isn't a quine, or elegant in the way that a one-liner is elegant, but instead it uses a program in which characters that are visual metaphors are executed to specify output that are in turn a texture of similar visual metaphors, which are in turn executable.

PATH Prime

Michael: I had a spare hour to hack, so I modified the path interpreter to implement path'. Actually, I didn't worry about the PETSCII vs. ASCII distinction (doesn't seem worth doing unless I implemented it on a C64), but I did do the following:

1. Since 10-print writes everything on a single line, when interpreting a path' program, path wraps the single line to a program the dimensions of the C64 text screen (40x24), discarding any extra characters. Note that given a single line full of '\' and '/' (generated by 10-print), wrapping it to different screen resolutions results in different path programs.
2. The 40x24 character grid is shifted one column to the right (41x24). A dollar sign (initiates path execution) is inserted in the first column - the rest of the first column is blank. In my hacked version of the path interpreter, you specify which row to place the $ in as a command-line argument.

Given a file (maze.txt) containing the output of 10-print, here's the command to interpret it as a path program:

    python ..\src\path --c64 14 -d maze.txt

The modified path interpreter accepts a new command line argument, --c64, which does the wrapping and first column stuff described above when loading the path program into the interpreter. The numeric argumnet after --c64 specifies which row to place the $ on. -d turns on debugging, which traces the program execution. Since a path program consisting of '/' and '\' only moves the point of execution around, the only way to see it do anything is to turn on debugging.

The attached files are:

• maze.txt - a run from the path implementation of 10-print
• row0-start.txt - a run of path using maze.txt as input with $ in row 0.
• row1-start.txt - a run of path using maze.txt as input with $ in row 1.
• row14-start.txt - a run of path using maze.txt as input with $ in row 14.
• path - my lightly hacked version of the path entry point.
• pathlang.py - my lightly hacked version of the path interpreter.

Just overwrite these files in your path install if you want to run this yourself. Behaves just like original path if you don't use --c64.

If you look at the attached runs, starting at row 0 it walks a short path before exiting. Row1 is a very short run, where execution bounces right back out. Row 14 is a long execution that makes it all the way across the maze.

Since maze.txt was generated by the path implementation of 10-print (I guess its short name should be +}}}}}+} instead of 10-print) and then consumed as a path program, this closes the loop. I'm half tempted to write a path interpreter in path and use that in this experiment, but aside from being cute (meta-circularity is always cute), we already know that computation is turtles all the way down, so I'm not sure it adds anything.