This sounds awfully lot like a premature optimisation, which as we all know, is the root of evil :-)
Why do you think that using Parsec will result in fewer transformations? (It will most likely result in fewer transformations *that you see*, but that doesn't mean much.)
I think you're right. I misunderstood the way the parsec library worked, and was trying to run before I could walk. However, it is a priority that I make this tool as fast as possible (as close to drive speed as I can). I wanted to take an "incremental" approach to optimization: writing small pieces, optimizing them, and then putting them together. I am also facing faculty skeptical that I can make things "fast" in haskell. (Currently, most DF applications are written in Python and C).
http://therning.org/magnus/archives/289 http://therning.org/magnus/archives/290 http://therning.org/magnus/archives/295 http://therning.org/magnus/archives/296
/M
Thanks for the references. They're great blog posts, very easy to follow. I didn't realize how simple Parsec was to use, at least in the Monadic form. For some reason, I thought it was more complex. I do have one question though. Do you always have to define your own Applicative instance for GenParser when trying to use the Applicative form? I noticed that both you and also RWH defined your own when explaining this form of Parsec. Is there no standard Parsec.Applicative in the library. Thanks again for your help, Jimmy