A fungeoid is a typically multi-dimensional language similar to Befunge.
Fungeoids are different from conventional imperative languages, where instruction go forward one at a time (barring threading), only breaking from their step-by-step process if told to via a GOTO or higher-level instruction of the same type. Instructions are, in these languages, only ever executed step-by-step or with a jump backwards (or forwards), in which the step-by-step continues.
In a fungeoid, on the other hand, instructions are executed by an "Instruction Pointer" or "IP" which has a sense of direction and, in some cases, velocity. The instruction pointer can move either forwards or backwards through the code, or in many other directions in higher-dimensional fungeoids. For example, a ">" director may tell the IP to start moving right/forward through the code, whereas the "<" will make it start moving left/backward. Fungeoids also, typically, have conditional directors. A conditional director tells it to move in a specific direction based on a specific piece of data (often the top of the stack).
Most fungeoids have some additional features to the concept of IP direction.
The first major feature, found in nearly all fungeoids (including the original fungeoid, Befunge), is multidimensionality. Many fungeoids, almost all in fact, exist in more than one dimension (like a normal languages does). A fungeoid in two dimensions will usually have four directors, conventionally ^v<> or ^V<>, that determine how the IP moves. Typically, a fungeoid has d*2 directors in total, where d is the number of dimensions it exists in.
Fungeoids do a LOT of playing with instruction execution order. That's really the whole thing that makes fungeoids cool. Examples of ways they mess with how instructions are executed are:
- As has already been mentioned, directionality is the thing that makes a fungeoid a fungeoid. Instructions are executed under a pointer which has a sense of direction, and after executing each instruction it moves one unit in that direction (or the new direction determined by that instruction).
- Conditional directionality, which is what really makes a fungeoid different from a normal imperative language. If instruction direction was constant, a fungeoid's code could just be "unraveled" by following the direction the IP should follow and writing down the instructions. However, since the IP can change direction conditionally, including a condition that is entirely determined by the user or a randomizer, it is MUCH harder to turn a fungeoid's code into flat, step-by-step, traditional imperative code.
- Trampoline Instruction: Jump over the next instruction
- A BREAK-like instruction that jumps from where it is executed to the next CONTINUE instruction (which may be the same instruction) in its path.
- Self-modifying code
Fungeoids often feature procedural, not functional, instructions. That is, a fungeoid's instructions are singular, non-nesting, and don't even accept arguments. This makes sense, as there are two ways that a function-based fungeoid could go: Either an instruction is a function and its arguments, OR an instruction is a function followed by its arguments in the following cells.
To allow data to be passed to procedures, many fungeoids are stack based, or more generally based on a spatial data storage mechanism (a data structure where there is a zero-argument getdata() instruction to obtain information from the data structure (as opposed to an abstracted-away map with variables)). Stacks are the most common one, as they are powerful (see things such as the Shunting-Yard Algorithm) and allow multiple data points to be extracted (unlike on a tape, where the number of data pointers corresponds 1-to-1 with the number of possible arguments).
Fungeoids often use single-character instructions, which makes it easier to program them (using a plain text file, as opposed to a spreadsheet-like mechanism).
Finally, in fungeoids, comments are often encoded by preventing the code from ever crossing that instruction.
Fungeoids, specifically Befunge, have the canonical goal of being REALLY hard to compile.