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