PATH and 10 Print Interpretation

From Maze

Revision as of 12:11, 29 June 2010 by JeremyDouglass (Talk | contribs) (Notes from the listserv)
Jump to: navigation, search

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.
Personal tools