Don wrote:
And even if an engine doesn't keep track of the moves, the driving program could use gtp commands to reset the state and replay the moves..?
It's my opinion that this would be poor engineering, a bad way to implement takeback. This absolutely requires something in the minimal protocol a lot more complicated that "undo." I'm really against the idea of requiring a GUI to perform this complicated operation in order to trick a program into taking back a move.
No, this doesn't require anything extra in the protocol, only that the GUI keeps tracks of the moves that have been made. The "black" and "white" commands suffice to set up a position.
Also, some programs will lose important state if the position is just reset as if it's from a completely different game. Even though this can be preserved by making the engine more complicated, it's a pretty ugly hack and the goal is to simplify the engine, not complicate it. And what if the engine is keeping a log of the game? Is it to view this a brand new position?
This on the other hand is a valid point.
My opinion is that the first revision of the GTP needs to be split into one minimal set, containing the absolutely necessary (*) commands for making it useful for tournament kind of use, and an extended set with useful but less critical commands that would be good to standardize early. Undo doesn't get into the first group but well into the second.
This message is cross-posted to the computer-go, gnugo, and gtp lists. From now on I will continue discussion about gtp only on the latter list. Those who want to take part in this should subscribe to the gtp list, see http://lists.lysator.liu.se/mailman/listinfo/gtp It's also possible to follow the discussion through the list archive, available from the same page. Currently the list is configured to allow posting from non-members, but this may change later (i.e. if necessary for spam reasons).
/Gunnar
(*) Plus some completely trivial ones like name and version.