Re: Conway's Game of Life (cellular automata)

[Bill Richter <richter@math.northwestern.edu>]

   > you left open the question of how HTDP would propose to design
   > the Life program.
   
   I think my comments about abstraction relate to something HtDP says about
   the importance of creating abstractions, which should have well-defined
   contracts.  

Sorry, Anton.  I just mean the "overall" design.  You handled the
"local" design just fine, but I thought mine was adequate as well.

   > But I ran into all kinds of mutability problems, so the list of
   > list functional version was easier to code up!
   
   If you want to build a vector recursively, without mutation,[...]

Sorry, I used plenty of mutation, lots of `string-set!', even `set!'.
That's the usual C approach, but Scheme makes it hard.  E.g.  I needed
`string-copy' in order to be able to mutate the "rows" of my matrices:

(define life 
  (vector 
   (string-copy "                                               ")
   (string-copy "                   x                           ")
   (string-copy "                xxxx                           ")
   (string-copy "       x       xxxx                            ")))

   
Took me a while to see why I couldn't mutate this (shared structure):

(define life (make-vector 30 (make-string 80 #\space)))

 
   > This shows an inelegancy of the x/y approach: your function
   > `new-cell-state' does "the same thing" no matter what x & y are.
   
   I'm not sure I follow you.  x & y is simply a concise way to
   specify a set of nine cells, in this case, and potentially, a
   larger set, although you're saying that for this specific
   application a larger set isn't needed.

Maybe I'm making an OOP point.  I'm just saying that `new-cell-state'
doesn't need the values of x & y, but only the nearest cells, which in
x/y lingo are of course are described by

(x-1,y-1) (x-1,y) (x-1,y+1)
 
(x,y-1)           (x,y+1)
 
(x+1,y-1) (x+1,y) (x+1,y+1)

Surely you agree.  And it would work just as well to describe these
neighbors "relatively" instead of "absolutely" as I did:

nw n ne
w     e
sw s se

But then I referred to these nearest neighbors as 

(car top) (cadr top) (caddr top)
(car row) (cadr row) (caddr row)
(car bot) (cadr bot) (caddr bot))

which is pretty cumbersome, and I imagine slow as well, and I don't
see that as any improvement over your matrix approach, other than
being functional (no mutation).