PATH and 10 Print Interpretation

From Maze

(Difference between revisions)
Jump to: navigation, search
(Notes from the listserv)
(PATH and language ref)
Line 9:Line 9:
<blockquote>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.'''</blockquote>
<blockquote>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.'''</blockquote>
 +
 +
== PATH ==
 +
 +
[http://pathlang.sourceforge.net/ 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.

Revision as of 12:19, 29 June 2010

View this revision of PATH and 10 Print Interpretation.

Personal tools