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&#39;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> &lt;<a href="mailto:wagner.andrew@gmail.com">wagner.andrew@gmail.com</a>&gt; 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&#39;s my take on this: I&#39;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 &quot;fundamental design&quot; 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&#39;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 &lt;<a href="mailto:smazanek@steffen-mazanek.de">smazanek@steffen-mazanek.de</a>&gt; wrote:<br>&gt; I originally used a more general approach (probably similar to the one
<br>&gt; you refer to), but<br>&gt; kicked generality out in favor of simplicity. In teaching one should<br>&gt; probably just discuss<br>&gt; this aspect, but stay with the simple approach (I&#39;ll add a note to the<br>
&gt; wiki page :-)). In<br>&gt; contrast, for the real Haskell world such a library would be great. One<br>&gt; could even use<br>&gt; an abstract game specification and compute the corresponding core (if<br>&gt; existing and
<br>&gt; computation being feasible according to the complexity of the game).<br>&gt;<br>&gt; Two-Player-zero-sum games are very library friendly kinds of games.<br>&gt; However, interesting<br>&gt; &quot;other&quot; games are probably too diverse to be pressed in a general
<br>&gt; framework, aren&#39;t they?<br>&gt;<br>&gt; Henning Thielemann schrieb:<br>&gt; &gt; On Mon, 19 Mar 2007, Andrew Wagner wrote:<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;&gt; Steffen,<br>&gt; &gt;&gt; I&#39;ve done some chess AI programming in the past, so I&#39;d be happy to
<br>&gt; &gt;&gt; help with this project. I have some pretty fundamental design<br>&gt; &gt;&gt; suggestions that I&#39;ll write up for the wiki page.<br>&gt; &gt;&gt;<br>&gt; &gt;<br>&gt; &gt; As a spin-off, will there grow some library for general strategies in
<br>&gt; &gt; board games, like those described in &quot;why functional programming matters&quot;?<br>&gt; &gt; _______________________________________________<br>&gt; &gt; Haskell-Cafe mailing list<br>&gt; &gt; <a href="mailto:Haskell-Cafe@haskell.org">
Haskell-Cafe@haskell.org</a><br>&gt; &gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>&gt; &gt;<br>&gt;<br>&gt; _______________________________________________
<br>&gt; Haskell-Cafe mailing list<br>&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe
</a><br>&gt;<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>&quot;Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp&quot;
<br>&quot;Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell&quot;