The bifunctor instance for FreeF in combination with a "mapT f = FreeT . liftM f . runFreeT" reduces the clutter a bit. It would be interesting if the explicit recursion in toFiles could be replaced with another iterT, but I think the numbering would require some kind of zipping mechanism for FreeT "lists".
On Friday, March 7, 2014 4:20:01 PM UTC+1, Torgeir Strand Henriksen wrote: > > 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]. >> To post to this group, send email to [email protected]. >> >> >> -- 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].
