PATH and 10 Print Interpretation

From Maze

(Difference between revisions)
Jump to: navigation, search
(PATH prime)
Line 69:Line 69:
Jeremy: A succinct recap: 10 print outputs executable Path-prime 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.
Jeremy: A succinct recap: 10 print outputs executable Path-prime 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 ==
 +
 +
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:
 +
 +
# 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.
 +
# 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.

Revision as of 12:48, 29 June 2010

View this revision of PATH and 10 Print Interpretation.

Personal tools