[Haskell-beginners] Defining custom parser using Parsec

[Antoine Latter]

On Mon, Oct 18, 2010 at 4:58 PM, Jimmy Wylie <jwylie at uno.edu> wrote:
>
>> 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-Serialize-Get.html