A Countercall program consists of a sequence of procedure definitions. Each is on its own line, and consists of an identifier (the procedure's name), a colon, and a sequence of commands (each of which is a procedure name, or
-). Commands are separated by whitespace. Run length encoding is permitted on
- by appending a decimal number to them, e.g.
+12 is equivalent to
+ + + + + + + + + + + +.
Any line of the source code that contains no colons is treated as a comment, and ignored.
The program starts by running the procedure named
main, and with the counter set to 0. The
- commands change the value of the counter (it stores integers of unbounded size and can be negative in addition to positive or zero, e.g. running
-4 with the counter at 1 will set it to -3). Running an identifier will call the procedure with that name in a loop, a number of times equal to the value of the counter at the moment the loop started. (That is, changing the value of the counter after the loop starts running will not change the number of remaining iterations of the loop). Attempting to run a procedure a zero or negative number of times does nothing.
Procedures follow normal rules for returning and recursion, i.e. a procedure returns after the last command in it completes, and after a procedure returns the program will continue with the next iteration of its loop, or with the next command if the loop has finished. When the original call to
main returns, the program exits.
Countercall has enough data storage to make it possible that it's Turing complete, although it (intentionally) doesn't follow any of the standard patterns. (For example, it might be possible to use the height of the call stack as one counter, and the counter itself as a second, in order to make a Minsky machine.) However, it seems potentially hard to keep control of the program when the counter gets large (as it necessarily must – the language is just a push down automaton if the counter is kept bounded), due to any attempt to call a procedure necessarily running it a large number of times. As such, the computational class is currently unknown; the author suspects it is Turing complete, but that this may be hard to prove.