Gemooy

Gemooy is an esoteric programming language designed by Chris Pressey on December 2, 2010. It combines features from 2-ill and Etcha, and adds self-modification. It came about when the author noticed the tape-related semantics of 2-ill were essentially the same as those of BitChanger. There are also some passing similarities to LNUSP, but Gemooy's design was not (consciously) influenced by it.

Program structure
A Gemooy program consists of an unbounded two-dimensional grid of cells; each cell may contain one of three symbols,,  , or blank. A program text may contain any other symbols, but they are treated as blank cells upon program load. The symbols  and   have special meaning;   indicates the initial position of the instruction pointer,   indicates the initial position of the data pointer. All cells outside of the loaded program are considered to contain blanks.

Program state
Pointing into the grid is an instruction pointer. The instruction pointer is at any time moving in one of eight directions corresponding to the deltas (dx, dy) where -1 <= dx <= 1 and -1 <= dy <= 1 and not (dx = 0 and dy = 0). The instruction pointer is initially travelling southeast (dx = 1, dy = 1).

Also pointing into the grid is a data pointer. The cell under the data pointer can be "incremented", which means: Decrementation is the inverse operation.
 * If it is a blank, it becomes a.
 * If it is a, it becomes a.
 * If it is a, it becomes a blank.

Program execution
The cells that the instruction pointer passes over are executed. Executing  causes the direction of the instruction pointer's travel to turn 45 degrees clockwise if the cell at the data pointer contains a blank, 45 degrees counterclockwise if the cell at the data pointer contains , or not at all if the cell at the data pointer contains.

Executing  has an effect that depends on direction that the instruction pointer is travelling:
 * North = Move data pointer one cell north, skip instruction pointer over next cell.
 * East = Move data pointer one cell east, skip instruction pointer over next cell.
 * South = Move data pointer one cell south, skip instruction pointer over next cell.
 * West = Move data pointer one cell west, skip instruction pointer over next cell.
 * Northeast or Northwest = Increment cell at data pointer.
 * Southeast or Southwest = Decrement cell at data pointer.

Executing a blank does nothing.

The program terminates when the instruction pointer travels out of bounds, i.e. away from the populated grid and into empty space from which it cannot possibly return.

Examples
Draw an infinite line of 's extending eastward:

@@ % @ $ @   #      #       @# @           @           @      @   @

Toggle (between  and blank) the cells down the leftmost column until the   is reached:

%  @@   @@        @ #        @     @     @     @     @@ @   @   @

Draw a solid line of 's eastward until a , then turn around and draw a dotted line of  's westward on the line below:

%          @  @@      @@ @       @  @ @          @  @   $    @       #        #         @  # @#  @               @   @               @   #            @ @             @@             @@            @              @  @            @                 @             @               @                  #                   @  #@#    @                  #     @     @                  #         @  @                @           @@                @       @                 @     @

Computational Class
We show that Gemooy is Turing complete by reducing Boolfuck without I/O to it.

The Boolfuck tape cells are laid out horizontally as 0 = blank, 1 = #, with neighboring Boolfuck cells separated by a blank. (We avoid @ due to the difficulty of turning when these are used, as well as the extra complication of handling three different options when branching.)

The main entrance and exit paths of each command are at the >'s. Matching [ and ] translations have two additional direct paths between them, denoted with -'s.  It may be necessary to stretch these vertically to ensure the extra paths don't collide with intervening commands.

GEMOOY
Over the summer of 2011 Gemooy provided the basis for a visual/conceptual art project, titled GEMOOY, by Gareth Jackson (hereafter misen23), in baffled consultation with Chris Pressey. Detailed visual forms were produced by elaborating the Gemooy programs shown above by a method probably only known fully to misen23, but which the language author understood to be a "perhaps cellular-automaton-like" process, in which graphical forms (GRAPHICONS) were put in place of the,  ,   and   symbols, and extended beyond the confines of a single grid cell to interfere or combine in some way with neighbouring forms (I'm explaining this as best I can.  An explanation by misen23 can be found in the GEMOOY project NOTES.)

GEMROOTD
Some discussion, between misen23, Chris Pressey, and User:Sherman (a project observer), of the constraints that the design of the Gemooy language imposed on the GEMOOY project, resulted in the proposal, by User:Sherman, of a variant of Gemooy called GEMROOTD intended to be more suited to visual recombination.

Gemooyio
Being essentially a "visible" language, Gemooy does not include any external input or output interface; the idea would be that input to a program would be "drawn" in the playfield alongside it before execution, and execution would likewise "draw" the output to the playfield.

However, adding input and output streams to communicate externally could be useful in e.g. a setting in a Unix-like operating system with pipes and so forth; the author proposes the following trivial variation called Gemooyio. When a  is executed, the effect is as given above, but with the following changes:


 * Northeast = If cell under data pointer is blank, output a 0 bit, otherwise output a 1 bit.
 * Northwest = Increment cell at data pointer.
 * Southeast = Decrement cell at data pointer.
 * Southwest = Wait for a bit to arrive on the input stream; if 0, write a blank under the data pointer; if 1, write a ; if a signal indicating there is no more input, write a.

It is recommended that the input and output should be considered unbuffered; i.e. if input is coming from a keyboard, input bits are available as soon as reasonably possible after a keystroke is registered. It is also recommended that, if communication occurs in the domain of ASCII characters, character codes are transmitted in eight-bit sequences with the LSB first.

External resources

 * in Javascript/HTML5
 * entry in Chrysoberyl