Fernan Bolando writes:

On Sun, Jul 19, 2009 at 7:40 AM, wren ng thornton wrote:

...

Fernan Bolando wrote:

...

The intention is z0 is a system parameter and database, it contains a set of info needed to define a particular simulation

A single-constructor ADT, especially with the labeled-fields syntax, is pretty close to C structs; no need to reinvent them and give yourself headaches.

Really, the only thing you should be using lists for is a variable-length sequence of elements drawn from the same type and distinguished only by their position in the sequence.

This is the kind of code recommendations I was looking.

I'd worked out a longer reply over the weekend, but wren got there first (It hadn't occured to me that anyone would write that much code without knowing about algebraic types, so thought something else was going on). I'd like to add that thinking about the C code for a programme like this is counterproductive. If you are doing various mathematical operations, it's better to go straight from the mathematics to Haskell, and work out the appropriate abstractions (in Haskell) for the operations you are using. You'll generally end up with much shorter code that is easier to maintain. It might be worth pointing out that you can do things with Haskell data structures that you can't do conveniently in C. For example, if you were doing something that involved calculating the determinants of matrices fairly often, but you didn't know in advance which matrices, you could define your own matrix type like this (roughly): data MyMatrix t = MM {theNumbers:: Matrix t, my_determinant:: t} make_matrix m = MM {theNumbers = m, my_determinant = determinant m } and then use make_matrix whenever you make a new matrix and my_determinant whenever you want a determinant. Now, although to a C programmer this looks like you calculate the determinant of every matrix, laziness means that you only calculate the ones you use, and calculate them at most once for each matrix. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk