My rule of thumb for what functions to provide in a library is to study Data.List to see if there is a list-based analog of the function I'm writing. If not, then I usually just hand-write the logic myself, the same way I would with lists.

On 3/7/2014 7:20 AM, 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] <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] <mailto:[email protected]>. To post to this group, send email to [email protected] <mailto:[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].

Reply via email to