[Haskell-cafe] Parsec to parse tree structures?

[david fries]

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
> >