So, your whole algorithm depends on effects taking place at an instance in time. Which maybe comes from the Magic layers system, I dunno.
But Quarry's effect isn't written to take place at an instant in time...it's a continuous effect. As is inheritance's effect. Which is what crj was trying to get at, I believe.
It does not depend on "effects taking place at an instant in time." I'm aware that continuous effects are meant to
always apply, and that they don't "occur" at instants in time. There's absolutely no "time" involved in the algorithm I'm discussing (nor is time involved in Magic's layer system, for that matter). In these lines from the last section of my script:
print "1. Play Quarry Before Buying Inheritance:"
s = State()
s.play_quarry()
s.inherit_village()
print "\t" + s.as_str() + "\n"
the concept of "time passing" is present only in the instructions "play_quarry" and "inherit_village". The game has only one state at any given time. Those two are the only instructions that mutate the game's state from one moment in time to the next. Specifically, it starts at an initial state, progresses to a state where a Quarry has been played, then progresses to a state where Inheritance has been bought. The algorithm I'm discussing doesn't involve any of that (and, as is demonstrated, is independent of the time order in which those two things occurred).
The algorithm I'm discussing occurs entirely within the call to as_str(), which does not mutate the game state; it merely determines a string representation of the game's current state at this
one instant in time. Of course, the algorithm progresses through a series of steps in order to reach its result, where certain things happen logically before other things. As
any algorithm must do. That doesn't mean that those steps represent a passage of time, or that the game was ever actually in the intermediate states you considered on the way to the final one.
Take the equation x = 2 + 3 * 5. In order to determine x, you have to follow a sequence of steps. You have to follow them in the correct order, and one step along the way is that you find one of the subexpressions is equal to 15. That doesn't somehow mean that x is equal to 15 from that moment in time until you finish the next step, after which it "becomes" 17. Just because you're following the steps in a procedure doesn't mean you're representing the passage of time.
Likewise, just because you consider a game state where Inheritance's effect has been evaluated, but not Quarry's, that doesn't mean you're saying the game actually
has that state at any given point in time. It's just an intermediate concept you use on the way to
evaluating the actual state at a given moment. Just like the subexpression 3 * 5 is an intermediate concept you use on the way to
evaluating x.
When translating such continuous effects into code, or making them instantaneous otherwise, you must add additional constraints, because "we can't go back". I believe in this case rather than saying it's a "priority" thing (which sounds arbitrary), it should be considered as a "dependency" thing. Quarry's cost-reduction depends on type, Inheritance effects type, so Quarry depends on Inheritance. Thus I(Q(G)) evaluated as a single point-effect doesn't make sense, because Q depends on I, and dependencies should always be evaluated first.
I entirely agree that a priority order is completely arbitrary, and would probably not be the desirable way to describe an evaluation order in Dominion. I also agree that a dependency order is probably what is intended.
I used the priority order
in the code only because my intent was to show that, as I keep saying,
the order of evaluation matters. Even if what you're evaluating is a game state at one instant in time. The simplest way to represent an order of evaluation is to assign a number to each thing you're evaluating. I wasn't trying to write a complete Dominion rules engine there.
My point, from the start, was that a hypothetical Dominion "Comprehensive Rules" document would explain what order to evaluate those effects. Nowhere am I saying that "dependency order" is somehow unacceptable. I'm just saying it's not called out anywhere (and doesn't really need to be, as far as I'm concerned). So one reason that the page counts of the rules that have been written for Dominion and those written for Magic are not directly comparable is because Magic's Comprehensive Rules are... more comprehensive. There are topics covered in Magic's rules that are not covered in Dominion's, but are nonetheless present (in fewer instances) there.