On Mon, Oct 18, 2010 at 4:58 PM, Jimmy Wylie
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).
If parsec turn out to not be fast enough for you, the attoparsec[1] library has a very similar interface to parsec but is expressly written for parsing data from bytestrings. I don't know what its backtracking strategy is, however. The cereal[2] library also supports the Alternative operations in the Control.Applicative, and is written for decoding low-level binary streams, so it presumably also support some form of backtracking. It doesn't ship with a "manyTill' function, which is what I would want to use for your data, but it doesn't look hard to write. I have no idea how well it would perform, though. Let us know how parsec works for you. Antoine [1] http://hackage.haskell.org/package/attoparsec [2] http://hackage.haskell.org/packages/archive/cereal/0.3.0.0/doc/html/Data-Ser...