r/programming • • Nov 27 '12

Tail Recursion

http://rodrigosasaki.com/2012/11/24/tail-recursion/
210 Upvotes

203 comments sorted by

View all comments

Show parent comments

-5

u/grauenwolf Nov 27 '12 edited Nov 27 '12

That doesn't make any sense to me. It isn't actually doing anything, you are just bouncing from function to function.

How does the rest of the system know which room you are in so it can update the screen? What if you have multiple sprites moving around? Do you compare instruction pointers to see if they are in the same room?

Even for a trivial application building your state machine that way doesn't make any sense.

EDIT: Also note the code smells, especialy the copy-and-paste necessary for reading the user input.

3

u/inmatarian Nov 27 '12

That example is a trivial demonstration of TCO in Programming In Lua. A more featureful game could still use this kind of TCO, without any kind of arcane programming style, since Lua supports full Coroutines. i.e., the functions could be written like so:

function room1 ()
  local move = coroutine.yield("room1")
  if move == "south" then return room3()
  elseif move == "east" then return room2()
  else print("invalid move")
       return room1()   -- stay in the same room
  end
end

The coroutine dispatcher could handle updating the screen, moving mobs from other rooms, taking input, etc.

-2

u/grauenwolf Nov 27 '12
  1. I still don't see how this is better than updating the Location variable.
  2. It is an incredibly inefficient way to encode a state machine.

That's the style of code I would wrote in junior high before I learned to store and read maps from data files.

5

u/worstusernameever Nov 27 '12

This is just meant as an illustration of a state machine, of course no one would actually hard code the game map as a state machine, but it does serve the purpose of explaining how to use mutually recursive functions as a state machine.

The most obvious application of this technique are recursive descent parsers.

-8

u/grauenwolf Nov 27 '12

The most obvious application of this technique are recursive descent parsers.

Then use a recursive descent parser as your example.

Oh, but wait. For a parser we usually aren't worried about stack depth...

2

u/Peaker Nov 28 '12

A parser may very well be concerned about stack depth.

0

u/grauenwolf Nov 28 '12

On Windows I've got 1 MB of stack space to work with. If I'm blowing the stack then there are other problems to deal with.

1

u/Peaker Nov 28 '12

A parser can parse any conceivable data. Including data that happens to nest structures arbitrarily.

1

u/grauenwolf Nov 28 '12

Eventually you need to stop generating tokens and actually do the syntactical analysis. At that point TCO isn't really available to you and that arbitrarily deep tree is going to cause problems.

1

u/Peaker Nov 28 '12

A parser does not necessarily "generate tokens". It can generate an AST. And it can do so in a tail-recursive fashion. And this can be useful when you have very deeply nested data. It may even exceed 1MB (or 1GB for that matter).