[Haskell-cafe] Parsec to parse tree structures?

[Ryan Ingram]

Here are some questions you have not answered that are quite important
for your design:

1) How important is retaining shared references?  In particular, is
the structure mutable after being read-in to memory?  If it is, and
you mutate an object, do you expect other references to that object to
be mutated as well?

2) If the answer to (1) is "not important", then how important is
parsing performance?  If you parse the same object more than once
(turning the directed graph into a tree), is that a problem?

This is an interesting problem and of course there are a lot of ways
to tackle it, but I think you need to elaborate a bit more on what is
needed.  If you want to maintain the "object graph" structure, you'll
treat the problem quite a bit differently than if you are happy to
convert it to a pure data structure.

  -- ryan

On Sun, Mar 14, 2010 at 9:03 AM, david fries <djf at gmx.ch> wrote:
> Hello Café
>
> Some time ago I wrote a parser for a project of one our customers. The
> format was proprietary and binary. The data was structured as a tree
> with tables pointing to sub tables farther in the file. (Well actually
> there was one or two cases where branches joined together, so I guess it
> was a directed graph.) Also it had no defined endianess, some tables
> were bigendian others were little endian and some were in their very own
> in-house-endianess.
> All in all, the typical binary data structure that has been in use and
> continuously extended for the last 15 years. You know the kind.
>
> Oddly enough, our customer never bothered to write a parser of their
> own. I wonder why.
>
> My parser was written in C# and wasn't particularly elegant, but it
> worked reliably. I was wondering how you would parse tree-like
> structures with Parsec (or other functional parsers)? Up to know, all
> examples I've seen were of sequential data. To parse trees, you'd
> essentially need to be able to follow pointers, parse whatever is there
> and then jump back. I guess I'd have to mess around with the internal
> state of the parser to do that, which is something I'd rather avoid.
>
>
> regards,
> dave
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>