That’s a really interesting idea, Gabriel. I’m building the parser with `xml-types`[1] in mind (since it seems to cover the spec pretty completely), but if there’s a way I could approach it (even devising a new type model) that would make it fit better with that plan then I’d be thrilled to do it another way. The idea mostly came about because I wanted to use `pipes` for another project without having to pull in another library just for a hand rolled parser (and whatever assumptions the designer imposed on it). In particular, I noticed the lack of any extant `attoparsec` parser for XML, so I thought that’d be a good first step.
Let me know your thoughts and I’ll put some time into it this week. The lens and `FreeT` stuff sounds very compelling, and getting a widely usable XML parser in the bargain can’t hurt. On Feb 15, 2014, at 4:24 AM, Gabriel Gonzalez <[email protected]> wrote: > I was taking a look at this the other day and I noticed that we can actually > use the `FreeT` idioms from `pipes-group` to provide a more strongly typed > interface to the XML document that preserves its nested structure. > > Right now, all the current XML libraries rely on generating a stream of > events which try to flatten the document into a linear stream. The issue > with this is that such a stream does not enforce the correct nesting in the > types and doesn't provide any good tools for manipulating groups. With > something like `pipes-group` we could actually represent the XML as an actual > nested data type that still streams all the data. As a bonus, we could even > use lenses to zoom in on tags and their children, too. > > I know that's probably more than what Jack had in mind, but I can contribute > the `FreeT` and lenses stuff myself if necessary. > > On 02/14/2014 01:08 PM, Jack Henahan wrote: >> I’m currently working on an attoparsec XML parser with the specific goal of >> using it with pipes-attoparsec and hopefully turning it into a pipes-xml >> kind of package. It’s not anywhere near release ready, but I’ll try to put >> more serious effort into it since there’s more interest. >> >> But oh, god, XML is a nightmare. >> >> On Feb 6, 2014, at 10:33 AM, Rodlogic <[email protected]> wrote: >> >>> I have been using pipes-http for the past few days and I am now at a point >>> where I need to parse xml responses. I don't need validations and I don't >>> need to parse the XML into a DOM but instead would like to parse it >>> directly into my own data structures (a la what existing JSON parsers are >>> doing in Haskell). And of course, sane dependencies is also important. >>> >>> Is there an existing lightweight xml parsing package that I could use with >>> pipes? If not, does it make sense to build one using pipes-parse? >>> >>> I am somewhat new to Haskell, so any pointers are well appreciated. >>> >>> thanks! >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Haskell Pipes" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
