1r

This language is a derivative of 2L.

1r is a language which has "one" instruction (ergo the 1, a la 1L) and has three dimensions (ergo the r, because 'L' is 76 (2 * 38) in ASCII and 'r' is 114 (3 * 38)).

The idea behind 1r is kind of like 1L_AOI, but the execution is completely different and the values map onto 2L. Therefore, I consider 1r to be a 2L derivative rather than a 1L_AOI derivative. To that end, I'm sorry for taking the name "1r" instead of calling it "1r_a" or something. If anyone really cares, I'm okay with renaming this language to something like that.

2L is called "The Two Language" but 1r is called "one r", or maybe "(the word for 1 with which one would say "1 instruction" in the language in question) (the word for the sound that r would represent in the language in question, or the most accessible rhotic sound, or the most accessible laminal approximant)". For example, in Spanish, 1r might be pronounced "uno ere". In Japanese, "1 instruction" is "1つの指示" which is pronounced "hitotsu no shiji", so ideally it would have that word in it. (I'm not sure if this would make it less accessible and harder to pronounce.)

Code

1r code must be in the form of a 3D matrix or 3D array. How exactly the array is stored and formed is up to the user and the interpreter, but keep in mind that this means 1r code is not at all optimized for being represented in a textfile.

Data

The data is in a tape like 2L or Brainfuck, and it starts at the first cell like the latter instead of the third cell like the former.

Symbols

1r splits the possible symbols into "whitespace" symbols which are NOPs and "non-whitespace" symbols which aren't. Ideally, the user can explicitly indicate which symbols are whitespace, and all symbols which aren't whitespace count as non-whitespace.

For the sake of clarity, any non-whitespace character will be represented by O because it's easy to type.

Movement

The pointer movement of 1r is kind of distinctive. The (x,y,z) coordinate starts at (0, 0, 0) like many other languages. As long as it doesn't encounter any non-whitespace, the x-coordinate will be incremented, then the y-coordinate, then the z-coordinate. This keeps happening in that order.

This means that by default, it ends up moving in a diagonal line deeper into the 3D matrix in the long run. Basically, you can think of ourselves as standing with the face of a cube in front of us. The pointer starts in the top left corner near us. It moves forward (deeper into the cube, away from us), then down, then right. Remember this terminology, it's important.

There are probably other languages that work this way.

Encountering Non-Whitespace

After every increment, the code pointer checks the cells in "front" of it i.e. one further in the direction it just went.

It checks the cells in the table, assuming the current position is (x, y, z) and the next position is one greater than the previous one:

Incrementing	Checked Cells
x	(x+1,y-1,z-1), (x+1,y-1,z), (x+1,y-1,z+1), (x+1,y,z-1), (x+1,y,z), (x+1,y,z+1), (x+1,y+1,z-1), (x+1,y+1,z), (x+1,y+1,z+1)
y	(x-1,y+1,z-1), (x-1,y+1,z), (x-1,y+1,z+1), (x,y+1,z-1), (x,y+1,z), (x,y+1,z+1), (x+1,y+1,z-1), (x+1,y+1,z), (x+1,y+1,z+1)
z	(x-1,y-1,z+1), (x-1,y,z+1), (x-1,y+1,z+1), (x,y-1,z+1), (x,y,z+1), (x,y+1,z+1), (x+1,y-1,z+1), (x+1,y,z+1), (x+1,y+1,z+1),

I think it checks the cells which satisfy the following conditions, but I'm not quite sure:

• They weren't adjacent to it before the last increment.
• They are adjacent to it now.

These 9 cells are then oriented in terms of "down" and "right" as mentioned in 1r#Movement. Basically, you can think of the pointer as starting in the top left. It moves forward, then down, then right. So assuming there's only whitespace in front of the pointer, it has just incremented forward, down is the direction it would move after the current increment and right is the direction it would move after the "down" increment. Up is the opposite of down and left is the opposite of right.

It is time to explain what non-whitespace in each of the cells in front of it does. Assume the value the data pointer points to is VAL.

	Left	Center	Right
Up	direction; sets direction to right if VAL is 0, otherwise sets direction to down	tape; increment VAL (+ in Brainfuck)	direction; sets direction to left if VAL is 0, otherwise sets direction to down
Center	tape; move the data pointer to the left (< in Brainfuck)	tape; takes input if VAL is 0, otherwise outputs VAL	tape; move the data pointer to the right (> in Brainfuck)
Down	direction; sets direction to right if VAL is 0, otherwise sets direction to up	tape; decrement VAL (- in Brainfuck)	direction; sets direction to left if VAL is 0, otherwise sets direction to up

A "tape" and "direction" instruction can occur at the same time, but if more than one "tape" or "direction" instruction is attempted, this is poorly-written code and you can throw an error.

After each instruction, the pointer is incremented once in whatever direction it now has (forwards, up, down, left, right) without checking the cells in front of it. Then, before it increments in the same direction, it checks the cells in front of it in that direction. As long as there's only whitespace in front of it, it keeps doing the "forwards, down, right" pattern by going forwards again.

The program ends when any of the values would be negative (i.e. it goes over the backwards, top, or left edge).