Well, I don't see much difference between what I did and what you propose here, considering the different frameworks we have. And the frameworks aren't so different. It is just that I consult the equivalent of these 'rule objects' in the daughter node. But that is also after the move has been made, and when that move is deemed illegal it is also unmade, and ignored in the parent (because its score is -INF). I could also differentiate different shades of illegality in the return code, if I wanted (as any score below -INF would effectively cause the move to be ignored), and take special action for an IllegalUnlessOnly code, like stashing moves for conditional later search, without subjecting them to the particular rule that made the move illegale 'IfNotOnly'. (Note that a move could be illegal for more than one reason, though; a forbidden trade could also expose your King!) And I also reacch a point where it can be concluded that no other legal moves are available, where I then have to take action to have the stashed moves searched. (In my case because bestScore is still at -INF after all other moves have been tried.)
It is just that I am to lazy for this cumbersome stashing of moves. Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion. But this time with the 'rule object' that rejected the move temporarily disabled, so these same moves won't get rejected again. This is of course very inefficient (especially without hash table...), but since it is a 'never happens' case, code simplicity prevails over run-time efficiency.
I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case. (It is not really only move: there could be several rule-violating moves that solve the mate. E.g. you might be able to capture the protected Golem with two different Golems.) But there have to be rule parameters that specify which rules can be switched off in this case. As I programmed it now I can only switch off the 'no trading when protected' rule. (Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi...)
BTW, this already turns out insufficient: the counter-strike rule can also have to be suspended. E.g. black Ka4, Pa5, Pd5, Gc6, white Nb4, Gc4. (Other pieces in start position.) White plays Nb4xc6, for a discovered check. Pd5xc4 could cure the checkmate, but the counter-strike rule forbids this after NxG.
So I must also create ways to switch off more anti-trading rules. The enforcement of such rules (as well as checking and baring) are controlled by a 'property word' for each piece type, where the bits correspond to the various rules. (When you click the 'move' header in the piece table these properties are shown behind the piece value, in parentheses.) I guess I could implement the mateExemption parameter as specifying a mask, with which the property words will be ANDed in case no legal moves were found during the retry.
Well, I don't see much difference between what I did and what you propose here, considering the different frameworks we have. And the frameworks aren't so different. It is just that I consult the equivalent of these 'rule objects' in the daughter node. But that is also after the move has been made, and when that move is deemed illegal it is also unmade, and ignored in the parent (because its score is -INF). I could also differentiate different shades of illegality in the return code, if I wanted (as any score below -INF would effectively cause the move to be ignored), and take special action for an IllegalUnlessOnly code, like stashing moves for conditional later search, without subjecting them to the particular rule that made the move illegale 'IfNotOnly'. (Note that a move could be illegal for more than one reason, though; a forbidden trade could also expose your King!) And I also reacch a point where it can be concluded that no other legal moves are available, where I then have to take action to have the stashed moves searched. (In my case because bestScore is still at -INF after all other moves have been tried.)
It is just that I am to lazy for this cumbersome stashing of moves. Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion. But this time with the 'rule object' that rejected the move temporarily disabled, so these same moves won't get rejected again. This is of course very inefficient (especially without hash table...), but since it is a 'never happens' case, code simplicity prevails over run-time efficiency.
I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case. (It is not really only move: there could be several rule-violating moves that solve the mate. E.g. you might be able to capture the protected Golem with two different Golems.) But there have to be rule parameters that specify which rules can be switched off in this case. As I programmed it now I can only switch off the 'no trading when protected' rule. (Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi...)
BTW, this already turns out insufficient: the counter-strike rule can also have to be suspended. E.g. black Ka4, Pa5, Pd5, Gc6, white Nb4, Gc4. (Other pieces in start position.) White plays Nb4xc6, for a discovered check. Pd5xc4 could cure the checkmate, but the counter-strike rule forbids this after NxG.
So I must also create ways to switch off more anti-trading rules. The enforcement of such rules (as well as checking and baring) are controlled by a 'property word' for each piece type, where the bits correspond to the various rules. (When you click the 'move' header in the piece table these properties are shown behind the piece value, in parentheses.) I guess I could implement the mateExemption parameter as specifying a mask, with which the property words will be ANDed in case no legal moves were found during the retry.