(Ugh. Apologies for the long posts.)
So in my previous post I was referring to your definition of a "gain" instruction, like on Witch: "gains a Curse". That is, this is your high-level instruction, and it doesn't issue a gain command right away, unlike your high-level instruction for draw. That's the distinction that I don't think there is any basis for.
Well, like you said earlier, I'm just making definitions that do what the rulings say. My only basis is the rulings that exist.
All gain instructions that let you choose a card to gain, have an implicit "choose" instruction first. The choose part is not really part of the gain instruction. (I can point you to the relevant ruling on this.)
Agreed. The implicit "choose" would be in the high-level function. For example, there might be GainCardMatchingCostRange function that Workshop could use, and it would include a choice.
I also agree that the "choose" part is not really part of the gain instruction. That's one of the points I've been trying to get across: the low-level gain function is the
only thing that counts for things like Trader. The high-level function might use the word "gain," but it encompasses things that happen before
really gaining (namely, the determination of the specific card to gain), and it might fail to lead to an actual gain in come circumstances.
So all actual gain instructions have an explicit card as a parameter.
Yes!
Workshop really says: "Choose a card costing up to $4. Gain it."
Exactly.
But Witch just says: "Gain a Curse" (for each other player).
I'm not sure what distinction you're making here. I'd say that it "really" says something like: "Select a/the Curse visible in the Supply. Gain it." Either way, I hope we agree that "gain a curse" ultimately means you do an actual (Trader-visible) gain on the specific card that's the Curse on top of the Curse pile, unless the Curse pile is empty, in which case no (Trader-visible) gain occurs.
You're right that a gain instruction first fires when-would-gain, before the actual gain. But that doesn't mean that the high-level part doesn't have the card as a parameter. Actually it does.
I disagree.
We already agree that there's an implicit "choose" that's not part of the actual gain. The high-level instruction is the thing that
does that choosing. (That's the entire reason I make the distinction in the first place.) You can't pass the specific card that got chosen... as a parameter to the thing that's going to choose it!
What the high-level instruction has as parameters are the
criteria for selecting specific card.
Here's a high-level instruction that Workshop might use. Its parameters are a min cost and max cost. Workshop would call it with MIN = $0 and MAX = $4:
GainCardMatchingCostRangePlayer P gains a card with (MIN <= cost <= MAX):
find all cards visible in the supply with (MIN <= cost <= MAX)
if any cards were found:
player P chooses a specific card C from them
player P gains specific card C # using GainSpecificCard(P, C)
else
nothing happensA gain instruction always has a specific card in mind. Workshop doesn't let you choose an empty pile, because you have to choose a specific card, not a pile. (I can point you to the relevant ruling on this too.)
We agree on this. That's consistent with the high-level instruction I just said Workshop might use. You choose a card from among the ones visible in the supply that are in the given price range. There's no way to select an empty pile; there's no way to select a pile at all.
So the high-level gain instruction, which comes after the choose instruction,
No. The thing I'm calling the high-level instruction
is the implicit choose instruction.
will have a specific card as a parameter.
No. Again, you can't pass the chosen card as a parameter before it's been chosen.
For Witch it's the top Curse card in the Curse pile. For Workshop it's the specific chosen card. For Thief it's the specific trashed card.
Correct, correct, and correct. But they don't get passed to the high-level instruction; they get passed to the low-level instruction, which is the one that takes a specific card as a parameter.
Similarly, a draw instruction references the top card of the player's deck.
It references it internally, yes. Once it exists (and assuming it ever does exist).
But the draw instruction doesn't get passed the specific card as a
parameter (i.e. the specific card doesn't get chosen by the thing that issued the draw instruction). That specific card may not even exist (rather, may not be
known) at the time you begin the draw instruction. The thing that tells you to "draw a card" can't say "draw(this here card on top of your deck)" because your deck might be empty at that point.
Rather, the thing that says "draw a card" simply says "draw_a_card." Or "draw." It doesn't know or care what card is ultimately going to get moved. The draw instruction is the thing that takes care of determining the specific card (if any) and moving it.
Now, ok, you
could say that "draw_a_card" is analogous to the high-level gain instructions that determine a specific card. And you could say that there's a corresponding low-level draw instruction that takes a specific card as a parameter and moves it into your hand. You'd call that low-level instruction
after the high-level draw instruction determined a specific card (after maybe reshuffling). In the case of a -1 Card Token, the low-level draw instruction would never happen.
But, unlike with gaining, making such a distinction with drawing doesn't really buy you anything. With gaining, you make the distinction because the rulings suggest that events don't occur until the low-level, "specific-card" gain happens. But the rulings for the token suggest that events occur on the high-level "draw_a_card" instruction at a time when it doesn't yet know what specific card it's going to draw.
So yeah, you can split off a lower-level draw instruction that operates on specific card by moving it, but it won't trigger any events, so there's no point in making that distinction.
I guess you could change the rules to trigger events off such a low-level draw instruction, but that'd be a different game. You'd have to reshuffle before removing the token, and you couldn't get rid of the token by drawing when your deck and discard were empty.
So as far as I see, there is no difference between the gain and the draw instructions. Logically, they both first check if the specified card exists in the specified location;
Yes, but gain checks if the specified card exists up in the implicit "choose," which we seemed to agree is not actually part of a (Trader-visible) gain instruction. By contrast, draw checks if the specified card exists
as part of the (-1-Card-Token-visible) "draw_a_card" instruction.
Why are they different? Well, "would gains" sorta have to fire on the low-level instruction,
after an implicit choosing of a specific card. Otherwise, you couldn't have cards like Possession that manipulate the chosen card you "would have gained." And Trader would let you gain Sivers when you got Witched when the Curses were out, which wouldn't make any sense.
Drawing, I suppose, could have been defined either way. And it didn't really matter until Adventures. But if you had events on a low-level draw instruction, you'd have weird token interactions described above. And your hypothetical card wouldn't gain you $ on an empty deck. I think that would just seem wrong. The token-removal and the hypothetical $ shouldn't replace a
card; they should replace a
draw.
then potentially fire "when-would" abilities;
It happens in that order for gain.
But if draw fired these events
after it made the checks for existence, that wouldn't fit with the rulings we have.
So, to match with current rulings, draw has to fire "when-would" abilities
before it starts doing any reshuffling or checking for existence of cards. All that stuff is
part of drawing.
then potentially move the card and fire "when" abilities (currently not existing for draw).
Right.
EDIT:
Look, say I rename
GainCardMatchingName and
GainCardMatchingCostRange to
FindCardMatchingNameThenGainIt and
ChooseCardInCostRangeThenGainIt. Is that what you're getting hung up on? Does that make it clear that I'm saying those high-level instructions are not part of the actual gain, and that the low-level function (which takes a specific card determined by a higher-level function) is the only thing that's doing an actual gain?
Because I'm pretty sure we're defining gain the exact same way, and we're just using different terminology:
You say Workshop's instruction is really an implicit choose followed by an actual gain of the chosen card. I say Workshop performs a high-level instruction that first has a player choose a card and then performs a low-level gain instruction on that specific card.
(I believe) you say Witch determines a specific Curse card (the one on top of the pile), then performs an actual gain on that card. I say Witch performs a high-level instruction that first determines a specific card in the supply and then performs a low-level gain instruction on that specific card.
You say the choose part is not really part of the gain instruction. I say the high-level instruction itself doesn't count as a gain as far as "would gain" and "did gain" events are concerned; only the low-level instruction fires those events.
I mean, I really don't see what's different to the point that you think I have misconceptions about how gaining works.
