Recursion HALP

Hey /prog/, I must say my understanding of recursion is shit (never really dealt with recursion in all my days of writing bad code). How should I go about thinking about it?

inb4 flaming: I understand the recursive concept in some contexts, such as when it is used in a factorial function, but when it starts getting more ambiguous (say, exercise 5, ch. 2 from ANSI Common Lisp) it's ugly.

inb4 RECURSE MY ANUS

Try expanding the recursive calls: (fact 5) ==> (* 5 (fact 4)) ==> (* 5 (* 4 ...))

(Do this for whatever function it is you don't understand.)

>>9
Fuck you on? That's how an unoptimised recursive problem is solved by the computer.

>>11
No, you cuntlegging shiteyed pissmonger. Each step in >>7 is just like looking the state of the stack before the next recursive call. Tell me wanknibbler, what's the other way a stack-based computer would solve this? That is, the solution that doesn't involve building up a stack and having it look like one thing in >>7 at some point in time.

>>14
I never said 'variable', you mentalist. Stop fabricating memories.
Of course there's ambiguity in evaluation order, because >>7 does not fully show the entire evaluation.
Finally, yes I am aware that there are indeed some computers that do not use stacks. But all of the valves in those computers have long since died.

>>16
... 'fact' is the name of the function. It could be variable, but in a factorial, it most often is not.
And showing the entire evaluation will show you the order of evaluation.

Are you done trolling?

>>23
Again, why don't you fist F5 before repeating yourself?
Umm.... a function can be a variable.
Well done. I acknowledged this in the very post you were referencing. Observe:
It could be variable
Now, rinse and repeat for every fucking thing you decided to blurt out in your latest rambling, regardless of how many times you have repeated yourself. If you cannot find an answer, please redirect yourself to /g/ or /sci/ or something.

>>27
So now it is you who is being ambiguous. How delicious.
>>26
May I point out that my first post in this thread was >>10.
I'd also like to suggest you take a course on argumentation. And re-read >>22.

>>29
Are you even reading my responses?
fact could be a variable. It does not vary in most implementations of factorial. It is a function, which is not a mathematical variable. Therefore it could be a "C/C++" variable. IHBT. You cease expanding (and thus start evaluating) fact when it becomes the base case, here it is 1. So the diagram (not my diagram, please refer to >>28) would end up as (* 5 (* 4 (* 3 (* 2 (1))))) before the evaluation of the products. Which is the point and time (?,>>22) that you start to "do" the multiplications.

Now please, stop being an anus, I've had to repeat myself as many times as you here.

>>31
No, because with languages that do not bundle bigint support, it would overflow a 32-bit computer (and probably a 64-bit one too). Floating-point would have a similar story. Please define ``exact number''.
I said it was a function, and that it could (note the emphasis) be a "C/C++" variable in that you can pass it to another function as, say, a callback or something. You cannot call a "regular" variable (int, float, ...) as you would call a function. What does your example have to do with variables versus functions, anyway?

Clearly fact in >>7's example is being called as a function, not a variable ("C/C++", by which you mean Lisp) and (* 5 (* 4 (* 3 (* 2 (1))))) is merely a simplified representation of the stack, obtainable via iterative substitution.

Also, I'm going to bed. Enjoy throwing poor insults at the next person who decides to pick this up. Don't forget to ignore 90% of what they say, now.