When I was a much younger programmer and had the time to delve into the details, I spent a lot of time reading books about LISP implementation and its underlying theory. Alonzo Church's Lambda Calculus was part of that research. I drove my math profs nuts because none of the rest of the class was prepared to go there, but they wanted to and did. We got a lot of interesting conversation accomplished, but the rest of the class was left very confused and the syllabus didn't get completed. ;)

The nice thing about Perl (or Ruby, for that matter) is that one can do functional programming in it as well as imperative programming. One can look at objects, or one can look at the transition methods and data transformation and information flow. It's all a matter of the level of data abstraction that you model, and the actual language used is immaterial to the understanding embedded in your model.

Haskell does seem to be a very clean way of expressing abstractions. Perhaps, for my parser/equation solver, it would be very suitable. The next stage of our project is to use my solver in conjuction with the analog simulators and statistical correlative software, and that's an iterative situation more suited to the imperative, input-driven nature of a general-purpose language.

Looking at the statelessness of it (Haskell), I can see that that would help us were we to be looking at clustering the solution, but I think that there are enough equations to run with that any real cluster processor I could run this on would be happy solving the equations separately, as there are more equations to solve than there would likely be CPU nodes.