Haskell, Lambert, and the Clarke Ellipsoid

Math is best done in a functional language. I've browsed through the source of several map projection libraries, and none of them take a functional approach or use a functional language; some are simply imperative C, while others written in Java actually attempt to make map projections OO, and have super classes and inherited methods. Unnatural!! If math isn't functional, then nothing is. What I want to see in a projection library is the same thing I see in a map projection book: a clear, concise representation of the projection algorithm. Neither Proj4, nor its Java port, nor the Geotools library provides that clear representation. So I've started my own projection library, in Haskell.
Normally it's bad it start libraries that duplicate the functionality of other libraries; and in fact no one but myself is likely to ever use this Haskell port of Proj4, but I just can't help but thinking that map projection is a perfect application for Haskell. Everything is very mathy, which Haskell handles well, and 99% of everything is functional. Projection algorithms do not have side effects. Almost the entire library can be implemented in purely functional code. And no language is better, or more clear or more concise than Haskell for purely functional code. That's what Haskell is made for.
What will be interesting though, is after I have a few more projection algorithms implemented, seeing how I can hook up the library to the EPSG database, so I can pull projection parameters instead of having the user manually enter them all in. Proj4 has its own xml mapping from EPSG codes to projection parameters, and Geotools has its very own HSQL database of EPSG junk. I'll have to see what persistence options the oh so functional Haskell has to offer.