Re: Game of life

[Sean Devlin <francoisdevlin@gmail.com>]

1.  Is laziness breaking your call do take?  Do you need to wrap it in
a doall?
2.  After I slept on it, I came to prefer the agent approach to the
iterate.  The iterate is good for prototyping, but the agent will be
better for production because of this exact list issue you're seeing.
3.  Go Colts.

Sean

On Feb 7, 4:00 pm, Aaron Feng <aaron.f...@gmail.com> wrote:
> Ok, so far, I have taken some of Sean's suggestions since I only have
> limited amount of time to hack.  There are some parts of the
> implementation I do not like, and I cannot pinpoint it exactly.  You
> can see my latest change on github.
>
> I updated the run fn to take the board as input and also outputted its
> value after cell computation.  Replaced 2D Java array with persistent
> vector for a more functional implementation.  After that was done, it
> was fairly easy to decouple the printing from the cell generation.  So
> in theory, I should be able to run multiple iterations like so:
>
> (def board (seed (vec (repeat 20 (vec (repeat 20 :dead))))))
> (show-env (take 100 (iterate run board)))
>
> The above code doesn't actually work correctly.  I'm still a little
> puzzled as to why (take 100 (iterate run board)) doesn't seem to work.
>  The output appears to be incorrect when I was eyeing it.  It seems
> like the previous iteration is not being passed back into run.
>
>  Another problem is that take wraps a list around the result, so
> show-env fn would have to change.  Is there a better way to do this so
> show-env doesn't have to be changed?
>
> I'm also not a big fan of the way I constructed the looping algorithm
> for run and seed.  I would like to remove the explicit branching
> statements from it if possible.
>
> Thanks,
>
> Aaron