
smazanek:
Hello again,
I got a lot of interesting and useful comments on my posting about Haskell Chess. Somebody suggested using the program for benchmarks. Several people asked me to open the program for contributions. And others were just interested in the exercises.
It is probably the best to branch the development, so that we have a teachers' and a hackers' version (ease of understanding and learning paradigms vs. efficiency and implementation of full ruleset). I will do the necessary steps next week (svn, etc). Somebody already offered help for cabalizing hsChess.
hsChess has been cabalised, and is available now via darcs; darcs get http://www.cse.unsw.edu.au/~dons/code/contrib/hsChess/ You can also browse the source directly: http://www.cse.unsw.edu.au/~dons/code/contrib/hsChess/
Several people asked me for the exercises so I started the wiki page http://haskell.org/haskellwiki/Learning_Haskell_With_Chess on this topic. I will add more content when I am back to office.
Every contribution and discussion is welcome.
I am happy to host the code at the above url, unless Steffen, you have a better place to host the repository? -- Don

Hello again, first of all, thank you Don for your help in making hsChess accessible. I have to have a look at darcs and cabal first :-) I have added some more content and a discussion page to the wiki, please contribute your thoughts. Furthermore I added a link to the german project and task description used in the exercises; the English version will be the wiki (although it has no convert2tex function). Best regards, Steffen Donald Bruce Stewart schrieb:
smazanek:
Hello again,
I got a lot of interesting and useful comments on my posting about Haskell Chess. Somebody suggested using the program for benchmarks. Several people asked me to open the program for contributions. And others were just interested in the exercises.
It is probably the best to branch the development, so that we have a teachers' and a hackers' version (ease of understanding and learning paradigms vs. efficiency and implementation of full ruleset). I will do the necessary steps next week (svn, etc). Somebody already offered help for cabalizing hsChess.
hsChess has been cabalised, and is available now via darcs;
darcs get http://www.cse.unsw.edu.au/~dons/code/contrib/hsChess/
You can also browse the source directly:
http://www.cse.unsw.edu.au/~dons/code/contrib/hsChess/
Several people asked me for the exercises so I started the wiki page http://haskell.org/haskellwiki/Learning_Haskell_With_Chess on this topic. I will add more content when I am back to office.
Every contribution and discussion is welcome.
I am happy to host the code at the above url, unless Steffen, you have a better place to host the repository?
-- Don

Steffen Mazanek wrote:
Hello again,
first of all, thank you Don for your help in making hsChess accessible. I have to have a look at darcs and cabal first :-)
I have added some more content and a discussion page to the wiki, please contribute your thoughts.
Furthermore I added a link to the german project and task description used in the exercises; the English version will be the wiki (although it has no convert2tex function).
Best regards, Steffen
I stepped onto your mail and found it particularly interesting since I'm currently writing a chess client in Haskell, using GTK+, glade and the nice Cairo library :-). It is called LambdaChess! The code is completely embryonic and totally useless at the moment, but there's a base for a decent GUI interface, with an SVG board, so easily themable. There is also some base code for a PGN file parser written using Parsec, and the whole thing is cabalized. The pieces aren't even drawn yet, but that should be quite easy to do, and I've found a few nice SVG piece sets. The PGN parser doesn't completely parses SAN moves yet, nor does it parse NAG annotations. It doesn't properly validates the presence of the mandatory tags, and so on... I guess I should stop since it's going to be huge if I'm listing all the missing features :-). Ultimately, it'd be nice if this code was able to handle local games between two humans and also playing against the various chess engines (crafty, gnuchess, sjeng, etc...). If it was also able to connect to FICS, it would be the absolute greatness :D. If you or anyone else on this mailing list feels like joining the fun, please do! The code is available here: http://mu.org/~mux/LambdaChess/ Cheers, Maxime

On Mon, 2007-03-19 at 12:14 +0100, Maxime Henrion wrote:
I stepped onto your mail and found it particularly interesting since I'm currently writing a chess client in Haskell, using GTK+, glade and the nice Cairo library :-). It is called LambdaChess!
Cool! When you have something you want to show off, we could always do with more expositions & screen shots etc for the Gtk2Hs website like the things we've got here: http://haskell.org/gtk2hs/archives/category/screenshots/ And I'm glad someone is using the new SVG module that got added in the latest Gtk2Hs release :-) Duncan

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.
Maxime,
Handling different chess engines isn't hard. chess engine
communication is pretty standardized - you would just need to add
support for the winboard and/or UCI protocols. FICS is a little bit
harder, but it's just a pure test stream over a socket, somewhat like
IRC, but less defined. ICC (another chess server) has a slightly
better-defined protocol. I can get you more details on any of these
protocols (except maybe FICS, which I don't think is documented), if
you'd like. By the way, how portable is your graphics code going to
be?
Sounds like this will be an interesting project. I look forward to it!
Andrew
On 3/19/07, Duncan Coutts
On Mon, 2007-03-19 at 12:14 +0100, Maxime Henrion wrote:
I stepped onto your mail and found it particularly interesting since I'm currently writing a chess client in Haskell, using GTK+, glade and the nice Cairo library :-). It is called LambdaChess!
Cool! When you have something you want to show off, we could always do with more expositions & screen shots etc for the Gtk2Hs website like the things we've got here:
http://haskell.org/gtk2hs/archives/category/screenshots/
And I'm glad someone is using the new SVG module that got added in the latest Gtk2Hs release :-)
Duncan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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.
Maxime, Handling different chess engines isn't hard. chess engine communication is pretty standardized - you would just need to add support for the winboard and/or UCI protocols. FICS is a little bit harder, but it's just a pure test stream over a socket, somewhat like IRC, but less defined. ICC (another chess server) has a slightly better-defined protocol. I can get you more details on any of these protocols (except maybe FICS, which I don't think is documented), if you'd like. By the way, how portable is your graphics code going to be?
I haven't yet looked in details at the winboard protocol or UCI, but having used crafty and gnuchess in CLI, I have a pretty good idea how this is all working, and this is indeed what I intend to do. As for FICS, I have often played on it through telnet, so I have a good knowledge of this text-based protocol. I don't know of any standard for FICS, but it isn't strictly required to get something working. I'd be interested in ICC support too, but since it's not free, it'll have to wait :-). As for the portability of the my graphics code, I can just say it's GTK+, using Glade XML files, Cairo and SVG on top of Cairo. All of this is supposed to work fine on Windows, if that's what you were asking. I'm not sure about OS X but I think it could also work there. My primary target is UNIX. For those of you who know it, I think BabasChess under Windows sums up what I'd like to obtain in the end quite nicely, features-wise. I'm looking forward receiving your patches! ;-) Cheers, Maxime
Sounds like this will be an interesting project. I look forward to it!
Andrew
On 3/19/07, Duncan Coutts
wrote: On Mon, 2007-03-19 at 12:14 +0100, Maxime Henrion wrote:
I stepped onto your mail and found it particularly interesting since I'm currently writing a chess client in Haskell, using GTK+, glade and the nice Cairo library :-). It is called LambdaChess!
Cool! When you have something you want to show off, we could always do with more expositions & screen shots etc for the Gtk2Hs website like the things we've got here:
http://haskell.org/gtk2hs/archives/category/screenshots/
And I'm glad someone is using the new SVG module that got added in the latest Gtk2Hs release :-)
Duncan
_______________________________________________ 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

Sounds great! I can add patches for ICC, as long as your chess-server
code is flexible enough to allow for multiple possible servers. I can
also try to do some testing under windows. I think for this to be
popular, it will need to work there. As for playing on FICS through
telnet...wow, you're a much more patient man than I!
On 3/19/07, Maxime Henrion
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.
Maxime, Handling different chess engines isn't hard. chess engine communication is pretty standardized - you would just need to add support for the winboard and/or UCI protocols. FICS is a little bit harder, but it's just a pure test stream over a socket, somewhat like IRC, but less defined. ICC (another chess server) has a slightly better-defined protocol. I can get you more details on any of these protocols (except maybe FICS, which I don't think is documented), if you'd like. By the way, how portable is your graphics code going to be?
I haven't yet looked in details at the winboard protocol or UCI, but having used crafty and gnuchess in CLI, I have a pretty good idea how this is all working, and this is indeed what I intend to do.
As for FICS, I have often played on it through telnet, so I have a good knowledge of this text-based protocol. I don't know of any standard for FICS, but it isn't strictly required to get something working. I'd be interested in ICC support too, but since it's not free, it'll have to wait :-).
As for the portability of the my graphics code, I can just say it's GTK+, using Glade XML files, Cairo and SVG on top of Cairo. All of this is supposed to work fine on Windows, if that's what you were asking. I'm not sure about OS X but I think it could also work there. My primary target is UNIX. For those of you who know it, I think BabasChess under Windows sums up what I'd like to obtain in the end quite nicely, features-wise.
I'm looking forward receiving your patches! ;-)
Cheers, Maxime
Sounds like this will be an interesting project. I look forward to it!
Andrew
On 3/19/07, Duncan Coutts
wrote: On Mon, 2007-03-19 at 12:14 +0100, Maxime Henrion wrote:
I stepped onto your mail and found it particularly interesting since I'm currently writing a chess client in Haskell, using GTK+, glade and the nice Cairo library :-). It is called LambdaChess!
Cool! When you have something you want to show off, we could always do with more expositions & screen shots etc for the Gtk2Hs website like the things we've got here:
http://haskell.org/gtk2hs/archives/category/screenshots/
And I'm glad someone is using the new SVG module that got added in the latest Gtk2Hs release :-)
Duncan
_______________________________________________ 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

On Mon, 2007-03-19 at 14:27 +0100, Maxime Henrion wrote:
As for the portability of the my graphics code, I can just say it's GTK+, using Glade XML files, Cairo and SVG on top of Cairo. All of this is supposed to work fine on Windows, if that's what you were asking. I'm not sure about OS X but I think it could also work there. My primary target is UNIX.
The SVG cairo stuff does build and work on Windows. I didn't include it in the standard build of the installer since it depends on rather more C libs and made the download a bit bigger than I'd have liked for such a small addition. So we could do another build with that in. Deploying Gtk+ apps on windows is pretty easy, I'm going to write a bit about how to it some time, but in the mean time here's one I prepared earlier: http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe Users don't need GHC or Gtk+ installed, you just bundle all the .dlls and the download isn't too big I think (3.5M compressed installer for a 1Mb GHC-built .exe + all the Gtk+ dlls). I've got pre-prepared bundles of gtk+ .dlls that you can use when building an installer (and another bundle incuding the other header files and stuff needed to build Gtk2Hs from source): http://haskell.org/gtk2hs/win32/ Duncan

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"?

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

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
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

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
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"
participants (7)
-
Andrew Wagner
-
dons@cse.unsw.edu.au
-
Duncan Coutts
-
Henning Thielemann
-
Maxime Henrion
-
Ricardo Herrmann
-
Steffen Mazanek