Re: [Haskell-cafe] Haskell Chess

Same as the MIME case: http://web.engr.oregonstate.edu/~erwig/papers/Zurg_JFP04.pdfhttp://web.engr.oregonstate.edu/%7Eerwig/papers/Zurg_JFP04.pdf http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdfhttp://www.cs.rutgers.edu/%7Eccshan/logicprog/LogicT-icfp2005.pdf http://web.cecs.pdx.edu/~apt/jfp01.pshttp://web.cecs.pdx.edu/%7Eapt/jfp01.ps http://www.cs.yale.edu/homes/cc392/report.html It would be great trying to unify all of these (and many more) into a library. Following he AIMA structure could be a good start. At the moment I'm working on implementing some AI Planning systems in Haskell and wrote my own logic unification, for example. On 3/19/07, Andrew Wagner wrote:

Here's my take on this: I've thought for a while now that Haskell needs a general toolkit for AI. After all, functional programming has long been recognized for being good at AI, yet you rarely hear about it being done in Haskell. Anyway, my suggestion would be to concentrate on methods of AI. For example, if we implement alpha-beta polymorphically enough, it should be trivial to use it for any game that it makes sense to use it on. This kind of thing is what I was thinking of when I talked about some "fundamental design" ideas I had. Things like writing a Board type-class, so that you can implement any board representation you want to for chess. Or writing alpha-beta in terms of positions and moves, regardless of what kind of game you're talking about (I also think you simply must use unfoldTree, as this is a beautiful instance of it). Things like learning, and other general strategies, should be developed independently of any particular game, IMHO.

On 3/19/07, Steffen Mazanek wrote:

...

I originally used a more general approach (probably similar to the one you refer to), but kicked generality out in favor of simplicity. In teaching one should probably just discuss this aspect, but stay with the simple approach (I'll add a note to the wiki page :-)). In contrast, for the real Haskell world such a library would be great. One could even use an abstract game specification and compute the corresponding core (if existing and computation being feasible according to the complexity of the game).

Two-Player-zero-sum games are very library friendly kinds of games. However, interesting "other" games are probably too diverse to be pressed in a general framework, aren't they?

Henning Thielemann schrieb:

...

On Mon, 19 Mar 2007, Andrew Wagner wrote:

...

Steffen, I've done some chess AI programming in the past, so I'd be happy to help with this project. I have some pretty fundamental design suggestions that I'll write up for the wiki page.

As a spin-off, will there grow some library for general strategies in board games, like those described in "why functional programming matters"? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ricardo Guimarães Herrmann "Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp" "Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"