Thanks again, understanding the layering helps a lot! I've toyed with the 
code some more, and instead of limiting the stream to blocksize*4 and then 
chunking it, I wanted to chunk it and then limit to 4 blocks. This resulted 
in splitAtF, splitsAt, and unSplits. I also found the need for a "takes" 
with different return type (takesDE). There's a lot of boilerplate and 
recurring patterns in these definitions, and I wonder if there are some 
tricks to reduce it before I write something similar to the "either" 
function for FreeF. Here's the code: http://lpaste.net/3906682534246744064

On Thursday, March 6, 2014 6:55:25 AM UTC+1, Gabriel Gonzalez wrote:
>
>  Here is the code extended to also parse an int named `n2` after the four 
> blocks:
>
> http://lpaste.net/100766
>
> I find it helps to keep track of the nesting of functors/constructors like 
> this:
>
> FreeT constructor -> m -> Pure constructor -> r
> -- or:
> FreeT constructor -> m -> Free consturctor -> Producer a m -> {FreeT 
> constructor -> ...}
>
> If you always keep track which layer in the stack you are at then it's 
> easier to figure out what the compiler expects.  I almost never actually 
> look at the type error.  Instead I just use the location information from 
> the type error and then see if there is a missing or extra layer in the 
> stack at that code positoin.
>
> On 3/5/2014 7:19 AM, Torgeir Strand Henriksen wrote:
>  
> Thank you for the example, picking it apart and experimenting with it has 
> helped me grasp the workings of some of the pieces. The bigger picture 
> still eludes me however - how can it be extended if the archive file has an 
> "end-of-four-blocks" marker directly after the 4x10 MB data (right before 
> the integer that names the next blocks)? For simplicity, say it's another 
> integer. I imagine it involves another runStateT (parse decimal), but I'm 
> not sure if I also need another FreeT, or if they could be combined in a 
> single StateT.
>  -- 
> 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] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
>
>
>  

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