[Haskell-cafe] Haskell Chess

[Ricardo Herrmann]

Same as the MIME case:

http://web.engr.oregonstate.edu/~erwig/papers/Zurg_JFP04.pdf<http://web.engr.oregonstate.edu/%7Eerwig/papers/Zurg_JFP04.pdf>

http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdf<http://www.cs.rutgers.edu/%7Eccshan/logicprog/LogicT-icfp2005.pdf>

http://web.cecs.pdx.edu/~apt/jfp01.ps<http://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 <wagner.andrew at gmail.com> 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 <smazanek at steffen-mazanek.de> 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 at haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070319/492414ab/attachment-0001.htm