Programming advanced strategy

[Darren Cook <darren@xxxxxxxxxxxxxx>]

Last week, John Fairbairn posted this on rec.games.go. It didn't get much
reponse, but maybe be of interest to people on this mailing list. I'm
reposting it here with his permission.
----------------------------------------
The thread on advanced strategy set me thinking. I haven't finished my
thoughts, but I'd like to float one preliminary idea since there are so
many programmers in r.g.g. (I am not one). Perhaps they could comment on
whether this idea is worth pursuing.

I was wondering whether go concepts could be reduced to objects as in
object-oriented programming. Each object would have its place in a
hierarchy, and would have properties and methods (all of which could be
inspected, of course).

To give one rather poorly formulated example: if get_sente was an
object, one well defined method would be playing a sacrifice cut to set
up an atari (returning result = sente). Among the properties, there
would be some (ideally most?) that would be shared by most objects.
Liberties is one. If get_sente.own_liberties = 0 that may be a signal to
a calling routine that the sente move is bad. Sente and gote may also be
properties, aji may be one (a fuzzy one?).

These objects would belong in a repository or tool box. In themselves
they mean nothing. Skill would still have to be exercised by the
player/programmer in selecting tools for the job, and in modifying tools
into descendant objects, but one merit is that the game/program could
then be discussed in terms of clearly defined objects, and their
properties could be inspected.

There would be nothing original in this, but in the same way that OOP
brings more structure to programs and makes bigger concepts more
manageable, it may help pin down some go structure. Any views?

-- 
John Fairbairn