1*2*3*4 + 5*(6*7*8*9 + 1*2)
That is a bad example as no compiler that I can imagine would suggest more
parentheses in the latter expression.
Well,replace * by && and + by || and it will complain all the time...
Interesting. I am not sure that it would be a good idea to give more tasks
to the game engines. It would make it harder to make engines, and make the
engines less portable to other interface programs as the distinction
between gui and engine would be weakened.
But I also agree that it is a problem that xboard have to know the rules
of many different games. Already now all this knowledge about many chess
variants complicates the code too much, I think.
Indeed, much of what you say is true. But this is mainly meant for games
where just a hand full, or perhaps even only a single engine exists. Now
people programming such a game typically have to program the entire GUI
with it, including the graphical part, or use text interfaces. For them it
would be a huge simplification if they can control a fully graphical GUI
through the text interface of the protocol.
I would consider taking specific game knowledge out of xboard, and instead
make a plugin-structure, so a module for the actual game can be loaded at
run time. That would in some ways simplify the core code, and make it
possible for everyone to write plugins for any game - much in the same way
as everyone can now build their own engines if they wish to do so and have
the necessary programming skills.
Using plug-ins is a good idea. But a plug-in would duplicate many functions
of the engine, as the latter would definitely have to be able to do
move-legality checking or generate lists of moves. In fact what we now call
engine initially was nothing but a plug-in responsible for maintaining the
game rules, and XBoard still uses the first engine as such (keeping it in
sync in EditGame mode, for instance). So I think this idea would eventually
pan out to using a 'referee engine' for the plug-in, which would just be a
normal engine that fully implements the new protocol features (which in
principle are optional, controlled by 'feature highlight=1'), so that other
engines don't have to bother with that.
The advntage would be that the person writing the first engine for a game
would not have to code a eparate plug-in, but could draw on the engine for
that.
I can confirm from own experience with xboard 4.6 on Linux that it is
somewhat slow to start up. I can do some profiling to see what is taking
the time.
In the case I ws referring to this was a 12-20 sec delay during which the
main window stayed blank, and we were able to trace it to calls to the
X-server. There is already a lot of e-mail correspondence about this, but I
am not sure it is visible in a public place...
