My Unreliable Past

From Esolang
Jump to: navigation, search

My Unreliable Past is an esoteric programming language created by User:ais523 in 2014. It explores philosophical questions about the nature of program startup and termination. Other than that, it is quite similar to (but not identical to) Fractran.


Data in a My Unreliable Past program are stored in one of 24 variables, each of which can hold an arbitrary nonnegative integer (providing infinite storage through the use of bignums). These variables are each named using letters (specifically, all the capital letters in the English alphabet apart from J and V).

There are basically three operations that can be performed on these variables: adding constants to them, subtracting constants from them, and testing them for zero. A test for zero succeeds if the variable happens to be zero at the time, and fails otherwise; it never changes the value of the variable. Subtracting a constant from a variable fails if it would become negative, and succeeds (changing the value accordingly) otherwise. Adding a constant to a variable always succeeds (and changes its value accordingly).

Commands are grouped into transactions; there can be up to 32 commands in any single transaction. Running a transaction is, in most cases, equivalent to running all the commands in it in sequence. However, if any command within the transaction fails, the effects of all the commands that ran so far in the transaction are reversed, reverting the value of every variable back to the value it had at the start of the transaction, and the remaining commands are not run. Thus, a transaction only does anything if all the commands in it succeed. A single-command transaction is identical to the command itself (and in fact, My Unreliable Past does not really distinguish between these two cases).

A My Unreliable Past program consists of a circular sequence of transactions.


A My Unreliable Past command is written using a capital letter, then either + or - followed by a positive number (for a command that adds or subtracts a constant), or else =0 (for a zero test). Commands within a transaction are separated with commas; transactions are separated from each other with semicolons. In order to fit a My Unreliable Past program into a text file (which has a beginning and an end), it is acceptable to pick an arbitrary point within the program and break the program there, in order to make it into a linear rather than circular sequence of bytes.

For example:

+67; O=0, O+66; O=0, O

is a valid My Unreliable Past program. (It's possible to move any number of characters from the start to the end, or vice versa, without changing the meaning of the program.)

Whitespace is disallowed between the digits of a number, but otherwise permitted anywhere. Anything between opening and closing parentheses is a comment, and ignored; comments nest. All programs must contain at least one transaction, and an equal number of opening and closing parentheses (otherwise, it would be conceptually ambiguous as to whether any arbitrary program was entirely commented out, or not, because there is no point equivalent to the start of the program that can be known to be definitively outside all comments). No syntax not mentioned here is allowed, and a My Unreliable Past interpreter should reject programs that contain syntax errors.

Input and output

The variables I and O are special, in that they can change value "spontaneously". If at any time (except in the middle of a transaction) O holds a nonzero value, then after a random number of transactions have succeeded or failed, its value will be set to zero. When this happens, one Unicode character is written to standard output, whose codepoint is the value that O had just before it was zeroed, minus one. Similarly, if at any time (except in the middle of a transaction) I holds a zero value, then after a random number of transactions have succeeded or failed, one Unicode character will be read from standard input, and the value of I will change to that character's codepoint, plus one. Once standard input reaches end-of-file, I will continue these spontaneous changes from zero, but will reuse previous input, repeating the entirety of the input that was previously seen indefinitely. If no bytes are available (either due to end-of-file on standard input before any characters were read, or because standard input is blocking and waiting for more input), the program continues running; I simply fails to spontaneously change while waiting for more input. (Likewise, if a program is incapable of outputting due to an output pipe being full or similar problem, O will not spontaneously change until the output pipe becomes writable again.)

Program execution

When a My Unreliable Past interpreter starts up, each variable starts with a random integer, determined via the following algorithm: there is a 1 in 2 chance the variable is initialized to 0; a 1 in 4 chance the variable is initialized to 1; a 1 in 8 chance the variable is initialized to a 2-bit integer (picked uniformly in the range 2 to 3); a 1 in 16 chance that the variable is initialized to a 3-bit integer (picked uniformly in the range 4 to 7), and so on. (The pattern continues indefinitely, meaning that all integers have a nonzero chance of being chosen.)

The program itself, unsurprisingly, starts running with a random transaction. From then on, the transactions run in sequence, succeeding and changing variables or failing and leaving them alone, indefinitely (because the program forms a loop, and has no endpoint).

Computational class

My Unreliable Past is somewhat hard to classify. It is trivial to compile Fractran (that does not use too many prime factors) into a hypothetical version of My Unreliable Past that starts at a known point in the program, with known variables (and thus misses the point behind the language); you can use one variable for each prime factor in the Fractran program, and one more as a sentinel to record whether any changes have been made this cycle. This makes deterministic-startup My Unreliable Past Turing complete (even without the use of zero tests). However, the randomized startup means that literally any internal state the program reaches during normal operation is also a potential startup state, and thus a My Unreliable Past program can never know anything for certain about its past execution; any data it calculates will, to the very next transaction, potentially have been placed there randomly rather than having been calculated by the program.

As such, the best that a My Unreliable Past program can do is to restart calculations every now and then, getting further and further each time. Any program that wants access to unbounded storage (and thus potentially needs to perform complete loops in order to access memory) inevitably runs the risk of producing the "wrong" answer for whatever job it's trying to perform. However, it is possible to write a program which, if it ever produces a wrong answer, will follow up with an infinite number of correct corrections. (Such a program must also have the potential to output incorrect corrections, but those themselves can be corrected infinitely many times.)

It is impossible for a My Unreliable Past program to ever effectively halt. For instance, if there were any circumstances under which such a program, say, produced no more output indefinitely, it would be possible for the program to start up in that "halt" state, meaning that the program never produced any output ever. Thus, a program that wants to be "reliable" must keep performing the same calculations over and over again, ad infinitum, purely out of paranoia that everything it believes is wrong.


Hello, world!

This program outputs "Hello world!" with high probability, along with the potential for outputting a random character at the beginning of the string. After outputting, it loops indefinitely, doing nothing.

(Set A to 100 with high probability... around 1/589 chance of failure)
(Output the characters one at a time, keeping track of where we are with A)