>
> Message: 7
> Date: Tue, 29 Mar 2011 22:39:12 -0400
> From: wren ng thornton
> Subject: Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
> To: haskell-cafe@haskell.org
> Message-ID: <4d9297d0.7060...@freegeek.org>
> Content-Type: text/plain; charset=ISO-8859-1; for
On 3/29/11 4:40 AM, o...@okmij.org wrote:
Wren Thornton wrote:
This is often conflated with the iteratee throwing an error/exception,
which is wrong because we should distinguish between bad program
states and argument passing.
I guess this is a matter of different points of view on exceptions
Antoine Latter wrote:
> It looks like we can't quite fit Enumeratee into the Category
> typeclass (without newtypes, at least). That's a shame.
Yeah. Intuitively it looks like iteratees and enumeratees are excellent
candidates for Category and even Arrow. Unfortunately they can either
be monad
Hello,
>> (=$) :: Monad m => Enumeratee ao ai m b -> Iteratee ai m b -> Iteratee ao m
>> b
>> enum =$ iter = joinI (enum $$ iter)
>>
>> ($=) :: Monad m => Enumerator ao m (Step ai m b) -> Enumeratee ao ai m b ->
>> Enumerator ai m b
>> ($=) = joinE
>> --
On Tue, Mar 29, 2011 at 6:15 PM, Ertugrul Soeylemez wrote:
> Hello John,
>
> Sorry that I'm late. And honestly one day for request submissions is a
> bit narrow.
>
> I have a request, too: Right now it is difficult to compose
> enumeratees. An equivalent of (.) for enumeratees would be great.
Hello John,
Sorry that I'm late. And honestly one day for request submissions is a
bit narrow.
I have a request, too: Right now it is difficult to compose
enumeratees. An equivalent of (.) for enumeratees would be great. So
instead of:
joinI $ e1 $$ joinI $ e2 $$ iter
one could write
Thanks, I look forward to being able to use these new operators!
On Tue, Mar 29, 2011 at 8:22 PM, John Millikin wrote:
> 0.4.9 has been uploaded to cabal, with the new operators. Changes are in the
> replied-to post (and also quoted below), plus the new operators proposed by
> Kazu Yamamoto.
>
>
0.4.9 has been uploaded to cabal, with the new operators. Changes are in the
replied-to post (and also quoted below), plus the new operators proposed by
Kazu Yamamoto.
Here's the corresponding docs (they have examples!)
---
On Mar 29, 2011 10:42 AM, wrote:
>
> I'm keen to hear of the example that seem to require Iteratee's
> allocating additional resources. I'd really like to see if any of such
> cases can be cast it terms of regions, implemented via iterated
> Iteratee transformers.
Hello Oleg,
The first example
Wren Thornton wrote:
> This is often conflated with the iteratee throwing an error/exception,
> which is wrong because we should distinguish between bad program
> states and argument passing.
I guess this is a matter of different points of view on exceptions. I
am a fan of the model of (effectful
On Tue, Mar 29, 2011 at 7:50 AM, John Millikin wrote:
> Since the release, a couple people have sent in feature requests, so I'm
> going to put out 0.4.9 in a day or so.
>
> New features will be:
>
> - tryIO: runs an IO computation, and converts any exceptions into
> ``throwError`` calls (requeste
Since the release, a couple people have sent in feature requests, so I'm
going to put out 0.4.9 in a day or so.
New features will be:
- tryIO: runs an IO computation, and converts any exceptions into
``throwError`` calls (requested by Kazu Yamamoto)
- checkContinue: encapsulates a common patte
This isn't quite what I'm after. I want to pull chunks on demand (i.e. have
control over both the input and the output). Enumeratees don't allow me to do
that.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 27, 2011, at 7:58 PM, John Millikin wrote
Now THAT"s what I'm talking about. Augment such a solution with interruptible &
resumable data producers, and I'd have everything I need.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 27, 2011, at 10:54 PM, wren ng thornton wrote:
> In an ideal fr
On Mar 28, 2011, at 12:54 AM, wren ng thornton wrote:
On 3/27/11 9:58 PM, John Millikin wrote:
Resending is slightly more complex -- if the other end can say
"resend that
last chunk", then it should be easy enough, but "resend the last 2
bytes of
that chunk you sent 5 minutes ago" would be m
On Mon, Mar 28, 2011 at 8:06 AM, John Millikin wrote:
> On Sunday, March 27, 2011 9:45:23 PM UTC-7, Ertugrul Soeylemez wrote:
>>
>> > For setting a global timeout on an entire session, it's better to wrap
>> > the ``run_`` call with ``System.Timeout.timeout`` -- this is more
>> > efficient than t
On Sunday, March 27, 2011 9:45:23 PM UTC-7, Ertugrul Soeylemez wrote:
>
> > For setting a global timeout on an entire session, it's better to wrap
> > the ``run_`` call with ``System.Timeout.timeout`` -- this is more
> > efficient than testing the time on every chunk, and does not require a
> > spe
On 3/27/11 9:58 PM, John Millikin wrote:
Resending is slightly more complex -- if the other end can say "resend that
last chunk", then it should be easy enough, but "resend the last 2 bytes of
that chunk you sent 5 minutes ago" would be much harder. What is your use
case?
This does highlight on
John Millikin wrote:
> Good idea -- I've added an ``enumSocketTimed`` and ``iterSocketTimed``
> to the network-enumerator package at <
> http://hackage.haskell.org/package/network-enumerator
> >. ``enumSocketTimed`` is equivalent to your ``enumHandleTimeout``,
> but instead of Handle uses the mor
If the receiver can only accept very small chunks, you can put a rechunking
stage in between the compression and iteratee:
---
verySmallChunks :: Monad m => Enumeratee ByteString ByteString m b
verySmallSchunks = sequence (take 10)
-
This formulation does not let me control the production of compressed chunks
independently from the provision of input; a receiver may only be capable of
consuming a tiny amount at a time, and I may have to resend some chunks. Which
is the whole point: iteratee & friends are lopsided. They prov
On 3/27/11 11:38 AM, John A. De Goes wrote:
Enumeratees solve some use cases but not others. Let's say you want to incrementally
compress a 2 GB file. If you use an enumeratee to do this, your "transformer"
iteratee has to do IO. I'd prefer an abstraction to incrementally and purely produce th
On Sunday, March 27, 2011 8:38:38 AM UTC-7, John A. De Goes wrote:
>
>
> Enumeratees solve some use cases but not others. Let's say you want to
> incrementally compress a 2 GB file. If you use an enumeratee to do this,
> your "transformer" iteratee has to do IO. I'd prefer an abstraction to
> in
On Mar 26, 2011, at 4:24 PM, Mario Blažević wrote:
> On 11-03-26 04:33 PM, John A. De Goes wrote:
> Out of curiosity, have you looked at the monad-coroutine library? It's a
> more generic and IMO much cleaner model, though I wouldn't recommend it as a
> replacement because the enumerator and
Enumeratees solve some use cases but not others. Let's say you want to
incrementally compress a 2 GB file. If you use an enumeratee to do this, your
"transformer" iteratee has to do IO. I'd prefer an abstraction to incrementally
and purely produce the output from a stream of input.
Regards,
J
Hello Ertugrul Söylemez,
Good idea -- I've added an ``enumSocketTimed`` and ``iterSocketTimed`` to
the network-enumerator package at <
http://hackage.haskell.org/package/network-enumerator >. ``enumSocketTimed``
is equivalent to your ``enumHandleTimeout``, but instead of Handle uses the
more e
Hello John,
great stuff! Many thanks. I can't await the 0.5 release of your
library. By the way, I believe that the 'enumHandleSession' and
'enumHandleTimeout' enumerators from the 'netlines' library really
belong into this one. You will want to have timeout support, when
reading from a networ
On 11-03-26 04:33 PM, John A. De Goes wrote:
I noticed this problem some time ago. Beyond just breaking monadic
associativity, there are many other issues with standard definitions
of iteratees:
1. It does not make sense in general to bind with an iteratee that
has already consumed i
On 2011-03-26, Gregory Collins wrote:
>> Since the API is being broken anyway, I'm also going to take the
>> opportunity to change the Stream type so it can represent "EOF + some
>> data". That should allow lots of interesting behaviors, such as
>> arbitrary lookahead.
>
> The thing which I find i
On 3/26/11 4:33 PM, John A. De Goes wrote:
4. Iteratees cannot incrementally produce output, it's all or nothing, which
makes them terrible for many real world problems that require both incremental
input and incremental output.
For this one, enumeratees are the proposed solution. But for som
I noticed this problem some time ago. Beyond just breaking monadic
associativity, there are many other issues with standard definitions of
iteratees:
1. It does not make sense in general to bind with an iteratee that has already
consumed input, but there's no type-level difference between a "v
On Sat, Mar 26, 2011 at 8:03 PM, John Millikin wrote:
> On Mar 26, 10:46 am, Michael Snoyman wrote:
>> As far as the left-over data in a yield issue: does that require a
>> breaking API change, or a change to the definition of >>= which would
>> change semantics??
>
> It requires a pretty serious
On Mar 26, 10:46 am, Michael Snoyman wrote:
> As far as the left-over data in a yield issue: does that require a
> breaking API change, or a change to the definition of >>= which would
> change semantics??
It requires a pretty serious API change, as the definition of
'Iteratee' itself is at fault
Great work as usual John. I'm actually very happy to see
enumHandleRange: the next version of WAI will support partial files,
and I just implemented my own version of enumHandleRange over there. I
will gladly switch to your (most likely more correct) version.
As far as the left-over data in a yiel
34 matches
Mail list logo
