On Saturday, April 21, 2012 12:26:30 AM UTC+10, Craig Ching wrote:
>
>
>
> On Friday, April 20, 2012 9:07:49 AM UTC-5, Walter van der Laan wrote:
>>
>> You could start with pure functions to handle the game logic, e.g.:
>>
>> (defn new-game []
>> [[\- \- \-]
>>[\- \- \-]
>>[\- \- \-]])
On Friday, April 20, 2012 8:21:56 AM UTC+10, Craig Ching wrote:
>
> Ok, I've read that what I want to do is a no no. But this is the sort of
> thing I did in Scheme about 20 years ago (and because of that I'm probably
> misremembering ;-)).
>
> Basically I'm learning clojure and thought I'd wr
Another non-standard solution you could try is to use the state monad from
the monad library.
On Apr 21, 2012 3:22 PM, "Sergey Didenko" wrote:
> There is also a non-idiomatic way - transform your code to use a
> native Java data structure like ArrayList or primitive array.
>
> You may want it for
There is also a non-idiomatic way - transform your code to use a
native Java data structure like ArrayList or primitive array.
You may want it for the speed or if the mutable algorithm is more
readable. Anyway isolation of the mutable code is always a good
advice.
(defn new-game []
(let [board
On Friday, April 20, 2012 1:15:11 PM UTC-5, kurtharriger wrote:
>
>
> Game state does not have to be a map, it could be any datastructure
> you want, perhaps a protocol that is implemented by a concrete class
> in another JVM language. However, I avoid encapsulation unless there
> is a compel
On Apr 20, 9:43 am, Craig Ching wrote:
> Thanks for your input, I appreciate it.
>
> On Friday, April 20, 2012 10:16:51 AM UTC-5, kurtharriger wrote:
>
> > And you just need to keep the resulting state, no need to reapply the
> > moves.
> > Your main method might use a reduce or loop recur.
>
>
This is not the idiomatic way but you can stay quite close from your code by:
(defn game [ board ]
(fn [n i]
(cond
(= n :x) (game (assoc board i 'x))
( = n :o) (game (assoc board i 'o))
(= n :print) (println board
(defn (new-game (game (in
You can save state in an atom like this:
(def state (atom (new-game))) ; initial state
(swap! state move \x [1 1]) ; make a move
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that po
On Fri, Apr 20, 2012 at 7:07 AM, Walter van der Laan
wrote:
> You could start with pure functions to handle the game logic, e.g.:
We did this during swarm coding at ClojureWest on the game of Go, but
you could apply the same logic to any board game:
https://github.com/technomancy/swarm-go/blob/m
Thanks for your input, I appreciate it.
On Friday, April 20, 2012 10:16:51 AM UTC-5, kurtharriger wrote:
>
> And you just need to keep the resulting state, no need to reapply the
> moves.
> Your main method might use a reduce or loop recur.
>
> (loop [game (new-game)]
> (if-not (complete? gam
And you just need to keep the resulting state, no need to reapply the moves.
Your main method might use a reduce or loop recur.
(loop [game (new-game)]
(if-not (complete? game)
(recur (make-random-move game)))
--
You received this message because you are subscribed to the Google
Groups
By creating new game objects rather than mutating existing ones you could do
things you wouldnt otherwise be able to do. Perhaps you have different solver
strategies that you want to apply in parallel. Provided you can give each
solver its own copy this is trivial, but if your datastructures req
On Friday, April 20, 2012 9:07:49 AM UTC-5, Walter van der Laan wrote:
>
> You could start with pure functions to handle the game logic, e.g.:
>
> (defn new-game []
> [[\- \- \-]
>[\- \- \-]
>[\- \- \-]])
>
> (defn print-game [game]
> (doseq [row game]
> (println (apply str row)))
You could start with pure functions to handle the game logic, e.g.:
(defn new-game []
[[\- \- \-]
[\- \- \-]
[\- \- \-]])
(defn print-game [game]
(doseq [row game]
(println (apply str row
(defn move [game mark pos]
(assoc-in game pos mark))
(print-game (new-game))
(print-gam
Thanks for the help to both of you! Question, does it seem heavy handed to
do it this way? I mean, atoms are more for thread-safety, aren't they? I
don't have threads so it seems a bit much to use atoms for this. Am I
better off using recur and trying to loop? Or is this considered an
idio
to answer your question directly, you would need to do something like
this to make it work the way your example is set up:
(defn new-game []
(let [board (atom (into [] (repeat 9 nil)))]
(fn [n & [i]]
(cond
(= n :x) (swap! board assoc i 'x)
(= n :o) (swap! board assoc i 'o
You could keep the board in an atom so it can mutate; then try to find
maybe two good places for mutation to happen, your move and the program's.
With the rest being functional you'll avoid the problems of global state
while not being forced to fit your logic into a loop of some re-binding
that
Ok, I've read that what I want to do is a no no. But this is the sort of
thing I did in Scheme about 20 years ago (and because of that I'm probably
misremembering ;-)).
Basically I'm learning clojure and thought I'd write a tic tac toe game.
But not any tic tac toe, I want to write one where
18 matches
Mail list logo
