Previous attempts

Pan style

Used arrays to emulate particle properties, which didn't work out in any way possible. Also there was a lack of separation between particle properties and environment properties. I simply ran my head against the wall. Pan is also a huge piece of complex software. My Haskell skills were not up to the task of deciphering everything.

Horrible syntax, worse output and not neat at all.

Replacing Pan

Started writing what ended up as the afp-thing, but realized it would take more time than I had left for the first deadline.

Using Monads and imperative style

Tried something with Monad Transformers (having learnt those in the course and succumbing to the allure of new cool features that aren't completely understood). This was a panic attempt in order to get at least something to work properly (deadline now only 3 days away). No strict functions, I just tried to make some sort of imperative little language that would execute.

Got the code to compile and execute properly (when outputting as text in haskell). Failed miserably in trying to link Haskell and C++/OpenGL (Reaper). Can't remember if I tried HOpenGL, but I think I did and failed to install it (FFI trouble).

Horrible syntax and no optimization.

AFP project style

Next attempt at finishing the AFP course (begun 4 months after above version). Now I knew what would work, and what needed to be done. Never had time to produce complex enough examples to find out wether the system was up to the task, but it did manage to correctly handle CS's within CS's.

It only gave member functions (emit & simulate), so the class header along with the particle struct had to be provided by the user. That was something I knew how to do but didn't have time for (plus, it was more important to get the optimization parts in good order). This was on the right track. (exe needs to be in Reaper root dir to run, but it does show a ring of glowing particles being emitted at regular intervalls, each particle having degrading intensity and reacting to gravity).

This version still used a iterative calculation model where you had to have some state for each property. I abandoned this during christmas 2002 in favor of a language which avoids state as much as possible. It is still possible to have state, of course, but you have to be explicit about it.

Neater syntax, so-so output.