Same as the MIME case:<br><br><a href="http://web.engr.oregonstate.edu/%7Eerwig/papers/Zurg_JFP04.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://web.engr.oregonstate.edu/~erwig/papers/Zurg_JFP04.pdf
</a><br><br><a href="http://www.cs.rutgers.edu/%7Eccshan/logicprog/LogicT-icfp2005.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdf</a><br><br><a href="http://web.cecs.pdx.edu/%7Eapt/jfp01.ps" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://web.cecs.pdx.edu/~apt/jfp01.ps
</a><br><br><a href="http://www.cs.yale.edu/homes/cc392/report.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.cs.yale.edu/homes/cc392/report.html</a><br><br>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.<br>
<br>At the moment I'm working on implementing some AI Planning systems in Haskell and wrote my own logic unification, for example.<br><br><div><span class="gmail_quote">On 3/19/07, <b class="gmail_sendername">Andrew Wagner
</b> <<a href="mailto:wagner.andrew@gmail.com">wagner.andrew@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Here's my take on this: I've thought for a while now that Haskell<br>needs a general toolkit for AI. After all, functional programming has<br>long been recognized for being good at AI, yet you rarely hear about<br>
it being done in Haskell. Anyway, my suggestion would be to<br>concentrate on methods of AI. For example, if we implement alpha-beta<br>polymorphically enough, it should be trivial to use it for any game<br>that it makes sense to use it on. This kind of thing is what I was
<br>thinking of when I talked about some "fundamental design" ideas I had.<br>Things like writing a Board type-class, so that you can implement any<br>board representation you want to for chess. Or writing alpha-beta in
<br>terms of positions and moves, regardless of what kind of game you're<br>talking about (I also think you simply must use unfoldTree, as this is<br>a beautiful instance of it). Things like learning, and other general
<br>strategies, should be developed independently of any particular game,<br>IMHO.<br><br>On 3/19/07, Steffen Mazanek <<a href="mailto:smazanek@steffen-mazanek.de">smazanek@steffen-mazanek.de</a>> wrote:<br>> I originally used a more general approach (probably similar to the one
<br>> you refer to), but<br>> kicked generality out in favor of simplicity. In teaching one should<br>> probably just discuss<br>> this aspect, but stay with the simple approach (I'll add a note to the<br>
> wiki page :-)). In<br>> contrast, for the real Haskell world such a library would be great. One<br>> could even use<br>> an abstract game specification and compute the corresponding core (if<br>> existing and
<br>> computation being feasible according to the complexity of the game).<br>><br>> Two-Player-zero-sum games are very library friendly kinds of games.<br>> However, interesting<br>> "other" games are probably too diverse to be pressed in a general
<br>> framework, aren't they?<br>><br>> Henning Thielemann schrieb:<br>> > On Mon, 19 Mar 2007, Andrew Wagner wrote:<br>> ><br>> ><br>> >> Steffen,<br>> >> I've done some chess AI programming in the past, so I'd be happy to
<br>> >> help with this project. I have some pretty fundamental design<br>> >> suggestions that I'll write up for the wiki page.<br>> >><br>> ><br>> > As a spin-off, will there grow some library for general strategies in
<br>> > board games, like those described in "why functional programming matters"?<br>> > _______________________________________________<br>> > Haskell-Cafe mailing list<br>> > <a href="mailto:Haskell-Cafe@haskell.org">
Haskell-Cafe@haskell.org</a><br>> > <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>> ><br>><br>> _______________________________________________
<br>> Haskell-Cafe mailing list<br>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe
</a><br>><br>_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">
http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br></blockquote></div><br><br clear="all"><br>-- <br>Ricardo Guimarães Herrmann<br>"Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp"
<br>"Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"