So, we already know that TI-BASIC's control flow stack can be used to implement subroutines in TI-BASIC by abusing the "memory leak bug" to implement a return stack:

Code:

Another weird bug-thing that has been established before is that you can use unnamed For-loop variables to store data on the same control stack (on CSE and higher). Theoretically, this should make it possible to implement proper recursion in TI-BASIC by making use of just the control stack. Theoretically, of course. This would be entirely too impractical and unreasonable to actually try to implement. It could be a thought experiment at best. A hypothetical edge case in the development of static analysis tools, and even then probably not, because who would be insane enough to actually write something like that.

Therefore, behold, the Ackermann function:
Code:

To use, set M and N to those respective arguments, call AK using the method described above, and the result is in A. L1 needs to exist and have at least one element (but it is not accessed nor changed, and there are several alternatives available). We only need to store M and a return address on the stack, and it uses two tail calls. Stack depth scales with N, so it is likely to overflow. This means M is better stored in unary. This makes extraction slow, but it is clear we already didn't care about speed here. This has been an exercise in inanity from the very beginning.

Note: I haven't actually been able to test this. I don't have a CSE or a CE, which support the "unnamed For var" feature (yes I'm calling it a feature now). I'm pretty sure it should work though. (EDIT: Zeroko checked, it works)

Just in case that wasn't enough, a version that doesn't use real variables either:
Code:


Or, a version that returns a real in Ans, courtesy of Zeroko:
Code:

(both of these should be called using {M,N} in Ans)

Isn't this great? Non-primitive recursion using no reals and no lists! How cool is that! TI-BASIC is such a powerful and fully-featured language!

Programs abusing the End-stack are among the strangest extant species of TI-BASIC creature. I applaud you for your actually quite readable demonstration.

I hesitate to wonder aloud if it's possible to do push-down automata things with the control flow stack.

This is really, really slow.

For the variable-free version that returns a real:
To compute A(3,0)=5 takes 1 second.
To compute A(3,1)=13 takes 4 seconds.
To compute A(3,2)=29 takes 18 seconds.
To compute A(3,3)=61 takes 91 seconds.
To compute A(3,4)=125 takes 479 seconds.
(Times computed using startTmr & checkTmr, so they are only accurate to within ±1 second.)

A(4,1) (probably? definitely A(4,2), at least) & higher (& also some of A(<4,—)) will overflow the stack.

EDIT: For the non-variable-free version (modified to get rid of the need for C the same way my modification of the variable-free version did):
To compute A(3,0)=5 takes 0 seconds.
To compute A(3,1)=13 takes 1 second.
To compute A(3,2)=29 takes 7 seconds.
To compute A(3,3)=61 takes 38 seconds.
To compute A(3,4)=125 takes 197 seconds.
(Again to within ±1 second)
These times are faster than the variable-free version but still very slow.

Taking advantage of the fact that M is always decreasing, I also made a version that works without unnamed For variables (so I can finally try out my code myself):
Code:

(3,4) only takes 401 seconds!

Also, for each M, the highest N that doesn't overflow the stack (for this version, on this calc, with the amount of ram that I have free):
M=0 N=inf
M=1 N=502 (=504, 104 seconds)
M=2 N=197 (=397, 7161 seconds)
M=3 N=5 (=253, 2667 seconds)
M=4 N=0 (=13, 4 seconds)

I'm now trying to apply run-length encoding to the stack values for compression (which would be extremely effective for this algorithm and allow for more optimizations), allowing us to (eventually) calculate every value of this function that doesn't go over the int limit.

(I am feeling very normal about this function)