Now, when we’re designing a program, we’re thinking at multiple levels. We’re thinking about different aspects of that program. For example, we always have to think about is the program correct. Does it implement what we want it to implement? We saw in the zebra puzzle that we also want to worry about is it efficient. Maybe we have a correct program, but it takes an hour, and we’d rather have a program that takes thousandths of a second. We also have to worry about the debugging process of as we’re developing the program, we’re building up all sorts of scaffolding to make it run properly that maybe we won’t need later. Traditionally, we write our program. Some of what we’re written has to deal with having it be correct. Then some of the code interspersed in there deals with efficiency. Now we’ve talked about adding further code that deals with debugging it. We end up with this mess that’s all interleaved, and wouldn’t it be nice if we could break those out so that some of the debugging statements were separate, some of the efficiency statements could live someplace else, and the main sort of correctness program could, say, stay distinct from the other parts. This idea is called “aspect-oriented programming.” It’s an ideal that we can strive for. We don’t get it completely, but we should always think of can we separate out these different aspects or concerns as much as possible. What I want to ask is if I’ve written the function this way as this big generator expression rather than as nested statements, I can’t have count equals count plus 1 statements inside here, because there’s no place to put something inside a statement, and I’d like to separate the counting as much as I can from the puzzle to do the minimum amount of damage or editing to allow me to insert these bookkeeping nodes that do that counting. Let’s think about that. What would be the right way to do that? I’ll tell you what I came up with. This is the second-best answer I came up with. That’s to say, well, what am I doing? I’m counting iterations through the orderings, so maybe the place to insert my annotations is right here. I want this to be a debugging tool. For debugging tools, I’m willing to have shorter names, because they’re things that really aren’t going to stick around. I’m going to use them for a while, and then I’m going to get rid of them. I’m willing to have a one-character name here, although it bothers me a little bit. I can always rename it as something else. What I’ll do is I’ll just insert this call to the function c around each of my uses of orderings. I’m going to insert 1, 2, 3, times 5, 15 characters. There we are. I think that’s a lot less intrusive than putting in a lot of count equals count plus 1 statements. I’m pretty happy with that. What I’ve done here is defined a function called “instrument function,” which will count the calls that it takes to execute the calling of a function with the arguments. I haven’t shown you the definition of c yet, but when I show it to you, you’ll see that it keeps track of two counts– the number of starts, the times we started an iteration, started the for loop, that was measured with the c function, and the number of items that we got through. How many times did we go through that for loop? We initialize those counts to 0, we call the function, and then we say what do we get back. With the zebra puzzle, it only took us 25 iterations over 2,700 items. Puzzle2–this was the definition for when we took the original definition and then moved only one of the constraints up in the ordering. That gave us this number of iterations and items. I didn’t show the puzzle where none of the constraints are moved up. That would’ve taken even more. We see even here quite a reduction in the number of iterations in the counts, and this tells you how efficient we are.