
\section{\label{discussion}Discussion}

     The implementation creates an
``array of streams''.  An alternative approach is to create a ``stream
of arrays'', in which each update is performed on the whole lattice to
create a new global state.  It only involves minor changes to the
implementation to create such a stream of arrays
directly.  Alternatively one can feed the results of the given
implementation to a pipeline of \verb$elems$, \verb$transpose$ and
\verb$map (listArray bds)$ to produce a list of arrays.  There are some
advantages to the ``array of streams'' approach (apart from the fact
that it models process-parallelism).  Some existing Haskell
implementations do not handle array accesses very efficiently,
and in this
approach the array operations are confined to an initial stage where
the streams are ``tied together''.  In the ``stream of arrays''
approach array operations are needed in all updates.  On the other hand
it does seem more natural to have a list of arrays when it comes to
processing the data (the set of configurations) generated by a
simulation.

     The algorithm described involves state transition in an
essential way, but it is doubtful whether its description
would have been any clearer in terms of variables and assignments.
The explicit representation of sequences as infinite lists
seems just as natural.

