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.
Contents[hide] |
PATH
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."
