Your Minsky May Vary

Your Minsky May Vary is an esoteric programming language created by User:ais523 in 2015. The name came first, and then the esolang was designed around it.

Definition

The language is a derivative of Portable Minsky Machine Notation, but with one big difference: whenever in Portable Minsky Machine Notation you would need to specify a counter number, Your Minsky May Vary requires you to specify two distinct counter numbers, separated with |. For example, a valid Your Minsky May Vary program could look like this:

inc(0|1);
while(dec(1|2)) { dec(0|2); }

Semantically, each command does the same thing as it would in Portable Minsky Machine Notation, except that one of the counters is selected at random. The inc_by extension is still sugar for a sequence of inc instructions, each of which randomly increments one of its two counters. I/O extensions only affect a single counter out of the two that you give.

Programming in Your Minsky May Vary

The inspecificity of inc is annoying, but mostly not a big deal; you can increment a pair of counters and treat it like a single counter with their combined value. However, dec is rather harder to deal with. If the decrement was successful, everything is fine. If it was unsuccessful, though, you don't know whether the counter-pair was truly zero, or whether you just happened to hit a half of it that was zero at the time. (Using a register that's never incremented as half of your decrement can potentially help, because then you know that a decrement can only be successful hitting the other half, but clearly isn't enough by itself.)

Some building blocks can help to avoid this problem. First, note that just as the previous paragraph describes a zero test with false positives but no false negatives, there's a zero test for a single counter x with false negatives but no false positives; increment a junk counterpair y|z, then decrement x|y and if that fails x|z. For a nonzero counter, one of the tests will always succeed. For a zero counter, it's possible that both of them will fail (if both decrements hit x, or possibly if one decrement hits x and the other hits y or z if it's zero at the time and wasn't implemented.)

Unfortunately, this isn't enough to make programming in the language trivial by testing decrements both ways round: the "inverse zero test" in the previous paragraph can decrement a counter when it returns "possibly nonzero", but might not (it depends on whether it's y/z that was decremented, or x). A workaround involves starting y and z at zero, then trying to test them for zeroness afterwards to determine what happened to x. It's currently unclear whether this sort of technique can make it possible to write usable programs in the language, or whether it hits an infinite (or at least infinite-expectation) regress. (The latter seems likely, because if you determine that it was y or z that was decremented, that doesn't get you any closer to knowing what value x has; it probably hasn't been read at all all this time.) Perhaps some other technique could be used, such as restarting the program in response to bad luck (but even zeroing all the counters to simulate a restart is difficult).