[Haskell-cafe] Parsec to parse tree structures?

david fries djf at gmx.ch
Wed Mar 17 17:15:18 EDT 2010

Hi Ryan,

1) Retaining shared references was not important to us at the time. We
were only interested in the correctness of the values that were written.

2) Performance wasn't a big issue either. The parser was part of a
debugging tool we wrote for internal use. 

My my concern was how you would perform random access in a functional
parser. You're points are interesting too. I guess if we really had
wanted to work with parsed objects, retaining the shared references
would have been a must.

On Mon, 2010-03-15 at 14:57 -0700, Ryan Ingram wrote:
> 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
> >

More information about the Haskell-Cafe mailing list