So this is an update that I've added lens-based parsing to the `lenses` 
branch of `pipes-bytestring`, too, which you can find here:

https://github.com/Gabriel439/Haskell-Pipes-ByteString-Library/tree/lenses

Now you can do things like:

    import Lens.Family (over)
    import Pipes
    import Pipes.Parse (takes)
    import qualified Pipes.ByteString as PB
    
    main = runEffect $ over PB.lines (takes 3) PB.stdin >-> PB.stdout

You can also do it the old way, too.  `view lines` behaves like the old 
lines function and `view (from lines)` (using `Control.Lens`) behaves like 
the old `unlines`.  Note that the lens combinators work with both the 
`lens` and `lens-family` libraries.

The next order of business is seeing if there are any downstream libraries 
that benefit from lens-based parsing.  `pipes-attoparsec` would probably 
remain unmodified, but `pipes-binary` might benefit because it contains 
both serialization and deserialization routines.  Then you'd be able to do 
something like:

    binary :: (Monad m, Binary a) => Lens' (Producer ByteString m x) 
(Producer a m x)

Then you would be able to `zoom` on `Binary` elements and work directly 
with parsed elements:

    zoom binary :: (Monad m, Binary a) => Parser a m r -> Parser ByteString 
m r

Anything that you undraw would get serialized back to bytes.

Another downstream library that would benefit from lens-based parsing is 
Oliver's `pipes-tar`.  Since I've dropped the lens law requirement that 
means that he can define an improper lens to tar file entries that 
automatically discards unused bytes.

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

Reply via email to