Dear friends,
 I am working in a pipe manufacturing company we are making pipes as per 
API5L and are planning for API5CT. can any tell me the basic difference (in 
manufacturing and testings) between API5L and API5CT
On Sunday, December 15, 2013 11:22:47 AM UTC+5, 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