spimta's comments

Echoing stonemetal, I would recommend seeing if you can refactor so that you can keep your pure function as-is, and then lift it into some monad that takes care of the logging. The Writer monad can be a good way to do this elegantly.

Ah, I see what you mean now. This was deliberate--I want simulation time to be a precious resource that bots have to spend wisely. You can burn 4 seconds on one simulation that is more likely to give you valuable information, but then it's the only one you're going to get. Or you can do lots of small simulations that are less likely to return an answer. I agree that it's not very safe, which is somewhat unfortunate, but also serves to discourage bots that use precise timing as part of a strategy. Also, since timing out results in a defection rather than in some additional penalty, the risk isn't too large.

I actually fixed the number of rounds on purpose--I figure the Nash equilibrium in the classical iterated PD isn't very relevant in this wildly different version of the game, and I want to see what kinds of strategies emerge with fixed-size rounds.

I didn't explicitly forbid collusion, since it's tough to prevent it in practice; I would appreciate it if teams simply submitted one bot or several bots with different strategies.

When you call the time function, it will cut off the simulation once that 1/100th of a second limit is reached, no matter what happens inside the simulation. So even if your opponent simulates you or performs some expensive computation or even goes into an infinite loop, time will terminate in the allotted number of seconds plus the overhead. If that happens, though, it will return Nothing, so you won't have gained any information about what your opponent will do.

Yep, you're exactly right--I didn't actually add up the payoffs when I wrote that. You could potentially do better against tit-for-tat variants that have a certain chance of forgiving after a defection, but not against the naive, deterministic TitForTat.