I also upgraded `pipes-attoparsec` to use the latest `pipes-parse`. This was pretty straightforward since `pipes-attoparsec` doesn't have any bidirectional transformations, so the API did not change much. You can find the code here:
https://github.com/Gabriel439/pipes-attoparsec-1/tree/lenses At this point I'm pretty comfortable with the `pipes-parse` API. There is only one API decision which I am not sure about, which is whether or not to change the `Parser` type synonym to: type Parser e a m = StateT (Producer a m e) m ... or leave it as it currently is: type Parser a m r = forall e . StateT (Producer a m e) m r Once I figure that out I will merge the lenses stuff into the master branch of `pipes-parse` and start preparing packages for release to Hackage. On Saturday, December 14, 2013 10:22:47 PM UTC-8, Gabriel Gonzalez wrote: > > Okay, so I've recently been reworking pipes-parse to use lens-based > parsing again. You can find the latest draft here: > > https://github.com/Gabriel439/Haskell-Pipes-Parse-Library/tree/lenses > > The tutorial is mostly complete, so you can bring yourself up to speed > just by reading it: > > > https://github.com/Gabriel439/Haskell-Pipes-Parse-Library/blob/lenses/src/Pipes/Parse/Tutorial.hs > > > Long story short, I've decided that law-breaking lenses are worth it. > The best way to see why is to read the tutorial, but I can briefly > summarize it like this: If you package a transformation as a lens, you > can use it to transform both `Parser`s and `Producer`s. The rough > analogy is: > > * `Producer`s stay the same > * `Parser`s are the `pipes-parse` analog of `Consumer`s > * `Lens'`es are the `pipes-parse` analogy of `Pipe`s > > A lens can transform `Parser`s using `zoom` and it can transform > `Producer`s using `view`. > > Another benefit of using lenses is that now you can simplify > splitting/transforming/joining using the lens `over` function. > Previously you would have to write something like this: > > unlines . takeFree 3 . lines -- Just take the first three lines > > Now you can just write: > > over lines (takes 3) -- I renamed `takeFree` to `takes`, too > > `lines` is now a lens and when you apply `over` to it the lens > automatically splits and joins things for you. > > Right now these are all lenses, but in principle I could upgrade them > further to `Iso`s. The reason I keep them as lenses for now is to > encourage people to use `over` rather than explicitly splitting and > joining. This also makes people less likely to use them in a way that > would violate the lens laws. > > Note that there is no `input` any longer. The idea is that in the > parsing world lenses are the only transformations and parsers are > strictly consume-only (no `yield`ing). The observation that lenses > served as transformations in both directions was the missing piece of > the puzzle that I didn't figure out last time that I tried this. > > I also specifically CC:ed Jeremy Shaw on this message because this is my > long-delayed answer to his question for how to structure delimited > parsing using `pipes`. You use lenses to delimit the parser to a subset > of the stream. The simplest example is: > > zoom (splitsAt 5) aParserRestrictedtoFiveElements > > If anybody has any questions about how to translate old `pipes-parse` > idioms to the lens-based idioms, just ask me. Over the next week I'm > going to begin converting `pipes-bytestring` to use these idioms in a > `lenses` branch so that people will have more to play with to try out > this new way of doing things. > -- 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].
