sje wrote:Having a unified view of state variable management allows for easy expansion while at the same time avoiding idiosyncrasies. Stuff like posting (two different directives), random (a toggle), pondering (two different directives), sd/st vs level (conflicting directives), and new mode variables required for additional functionality. Without a general unification, the ugly never goes away. Without a general unification, the newcomer coder has to slog through a document loaded with references to a long-gone chess engine.
Except of course that by now some 1000 other XBoard engines also work this way. The random, st, sd, easy, hard, post and nopost commands are not deprecated, and belong to the core set of command an engine must have to be of any practical use.
And, like I said, much of what you propose is only a 'formal' advantage, which makes no practical difference. Who cares whether you have post/nopost (2 commands) or "post true"/"post false" (imagining those are the same command, just because they contain a space)? Note that 'sd' is not a conflicting directive, but an additional limitation to the search, orthogonal to the timing requirements. Only 'st' and 'level' are actually conflicting, and my intention is to allow
level 0 0 -N as a synonym for
st N in engines that support an extended level command (that can also handle multiple sessions). So specifying
feature xlevel=1 would get rid of the
st command. That
random is a toggle, (and consequently has to rely on
new for being put in a defined state) and the others not might be ugly, but considering that hardly any engine supports randomization anyway, hardly a burden on the programmer...
A go/search action can be bundled on a usermove directive just by adding another field; there will already be field definitions for a draw offer and a draw claim, so adding a third field requesting a reply does not affect the general unification. With this, the total count of directives sent will be less than that of the current scheme.
Like it would really matter to many whether you have to send
usermove e2e4 search
or
usermove e2e4
search
...
I think this kind of bundling is intrinsically bad, as you might not want neither usermoves nor searches to always accompany each other, so there would still be need for unbundled search and usermove commands, so that many of the same can go in a row (for forcing in a game or having the engine play itself). Having them as separate commands is much more flexible. Only for combinations of actions that need to be atomic bundling makes sense. And even then I would probably prefer providing general atomicity through individual 'semaphore' commands to protect the critical section. Like
hold
move a6b6
1/2-1/2 {repetition draw}
release
to tell the GUI it should not stop parsing commands for the current engine until it has seen the release (and thus the draw claim) before processing any input events from the opponent.
