Hi wren
Thanks for that explanation - it's by far the clearest description of
iteratees / enumerators I've seen.
Best wishes
Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
In part to help solidify my own understanding and usage, I wrote up
the following which shows a comparison of processing an input file.
Andrew Coppin originally posed the issue concerning strictness imposed
by using the ST monad for processing an input file.
This literate example shows a comparis
On 2/25/11 2:24 PM, Andrew Coppin wrote:
I've heard much about this "iteratee" things, but I've never looked into
what the hell it actually is.
Today I had a look at TMR #16, which is an explanation which I can just
about follow. It seems that it's actually a kind of fold - not unlike
the "strea
On 25 February 2011 20:38, wrote:
> The short version is that I think there is a more enlightening view of
> iteratees than as a kind of a fold. For me, it makes a lot more sense to
> think of them as operations in a particular abstract monad which has one
> associated operation, a blocking rea
On Fri, February 25, 2011 11:24 am, Andrew Coppin wrote:
> On 25/02/2011 02:16 AM, wren ng thornton wrote:
>
> > Or
> > converting the whole thing to an iteratee-style computation which is
> > more explicit about the type of stream processing involved and thus what
> > kinds of laziness are possibl
On 25/02/2011 02:16 AM, wren ng thornton wrote:
Given only this specification, the problem is overconstrained, which is
why you get too much strictness. That is, your types are too general to
allow you to do what you want (e.g., they allow the first Word16 to
depend on the last Word8).
Hmm, tr
On Thu, 24 Feb 2011 13:45:59 -0700, Andrew Coppin
wrote:
The input list is being read from disk by lazy I/O. With the original
implementation, the input file gets read at the same time as the output file is
written. But runST returns nothing until the *entire* input has been
compressed. So
Lazy ST is capable of returning values lazily. Not naively -- eg. if
you are writing elements to an STRef and then returning the contents
of the STRef at the end, then of course it will not return gradually
(who's to say that the last thing you do before you return isn't to
write [] to the STRef?)
On Feb 24, 2011, at 3:45 PM, Andrew Coppin wrote:
> OK, so I had a function that looks like
>
> transform :: [Word8] -> [Word16]
>
> It works nicely, but I'd like to use mutable state inside. No problem! Use
> the ST monad. Something like
>
> transform :: [Word8] -> [Word16]
> transform xs
On 2/24/11 3:45 PM, Andrew Coppin wrote:
OK, so I had a function that looks like
transform :: [Word8] -> [Word16]
It works nicely, but I'd like to use mutable state inside. No problem!
Use the ST monad. Something like
transform :: [Word8] -> [Word16]
transform xs = runST (work xs)
where
work :
On Thu, Feb 24, 2011 at 2:42 PM, Andrew Coppin
wrote:
>Anybody have any hints on how to get around this?
>>
>> Use a lazy state monad?
>>
>
> That's not going to work. It still needs to read the input to determine
> which monadic action comes next, and hence what the final result will be. So
>
Anybody have any hints on how to get around this?
Use a lazy state monad?
That's not going to work. It still needs to read the input to determine
which monadic action comes next, and hence what the final result will
be. So whether it forces the result or not, it still has to scan the
ent
On Thu, Feb 24, 2011 at 12:45 PM, Andrew Coppin wrote:
>
>
> Ah, yes, well there is one *small* problem... If you do that, the function
> becomes too strict.
>
> The input list is being read from disk by lazy I/O. With the original
> implementation, the input file gets read at the same time as th
OK, so I had a function that looks like
transform :: [Word8] -> [Word16]
It works nicely, but I'd like to use mutable state inside. No problem!
Use the ST monad. Something like
transform :: [Word8] -> [Word16]
transform xs = runST (work xs)
where
work :: [Word8] -> ST s [Word1
14 matches
Mail list logo
