On Mon, Mar 12, 2012 at 3:26 AM, Chris Smith cdsm...@gmail.com wrote:
With pipes-core (which, recall, is known to be unsound... just felt
this is a good time for a reminder of that, even though I believe the
subset that adds tryAwait and forP to be sound), you do get both (pipe
id) and (forP
On Mon, Mar 12, 2012 at 2:53 AM, Mario Blažević blama...@acanac.net wrote:
May I enquire what was the reason for the non-termination of idP? Why was
it not defined as 'forP yield' instead? The following command runs the way I
expected.
The identity in a homset is unique, and in the case of
On Sun, Mar 11, 2012 at 10:41 PM, Chris Smith cdsm...@gmail.com wrote:
On Sun, Mar 11, 2012 at 2:33 PM, Twan van Laarhoven twa...@gmail.com wrote:
I think you should instead move unwaits in and out of the composition on the
left side:
unawait x (p1 + p2) === (unawait x p1) + p2
This
On 11/03/12 23:41, Chris Smith wrote:
On Sun, Mar 11, 2012 at 2:33 PM, Twan van Laarhoventwa...@gmail.com wrote:
I think you should instead move unwaits in and out of the composition on the
left side:
unawait x (p1+ p2) === (unawait x p1)+ p2
This makes idP a left-identity for (+),
On Mon, Mar 12, 2012 at 3:26 AM, Paolo Capriotti p.caprio...@gmail.com wrote:
I wouldn't say it's unsound, more like not yet proved to be bug-free :)
Note that the latest master fixes all the issues found so far.
I was referring to the released version of pipes-core, for which
known to be
The Category law would be broken, though:
unawait x id == yield x !== unawait x
How did you get this equation? It's not even well-typed:
unawait :: a - Pipe a b m ()
yield :: b - Pipe a b m ()
Someone actually implemented a variation of Pipes with unawait:
On 2012-03-11 14:09, Paolo Capriotti wrote:
The Category law would be broken, though:
unawait x id == yield x !== unawait x
How did you get this equation? It's not even well-typed:
unawait :: a - Pipe a b m ()
yield :: b - Pipe a b m ()
I would expect that
(id unawait x) await
On Sun, Mar 11, 2012 at 1:25 PM, Twan van Laarhoven twa...@gmail.com wrote:
On 2012-03-11 14:09, Paolo Capriotti wrote:
The Category law would be broken, though:
unawait x id == yield x !== unawait x
How did you get this equation? It's not even well-typed:
unawait :: a - Pipe a b m ()
On Sun, Mar 11, 2012 at 7:09 AM, Paolo Capriotti p.caprio...@gmail.com wrote:
Someone actually implemented a variation of Pipes with unawait:
https://github.com/duairc/pipes/blob/master/src/Control/Pipe/Common.hs
(it's called 'unuse' there).
I actually agree that it might break associativity
On 12-03-11 09:09 AM, Paolo Capriotti wrote:
The Category law would be broken, though:
unawait x id == yield x !== unawait x
How did you get this equation? It's not even well-typed:
unawait :: a - Pipe a b m ()
yield :: b - Pipe a b m ()
You're right, it's completely wrong. I was
On Sun, Mar 11, 2012 at 10:30 AM, Mario Blažević blama...@acanac.net wrote:
It's difficult to say without having the implementation of both unawait
and all the combinators in one package. I'll assume the following equations
hold:
(p1 unawait x) p2 = (p1 p2) * unawait x -- this
On 12-03-11 12:39 PM, Chris Smith wrote:
On Sun, Mar 11, 2012 at 10:30 AM, Mario Blaževićblama...@acanac.net wrote:
(p1 unawait x) p2 = (p1 p2)* unawait x -- this one
tripped me up
I don't think this could reasonably hold. For example, you'd expect
that for any p, idP p == idP
On Sun, Mar 11, 2012 at 11:22 AM, Mario Blažević blama...@acanac.net wrote:
No, idP does terminate once it consumes its input. Your idP p first
reproduces the complete input, and then runs p with empty input.
This is just not true. idP consumes input forever, and (idP p) =
idP, for all
On 2012-03-11 14:46, Paolo Capriotti wrote:
On Sun, Mar 11, 2012 at 1:25 PM, Twan van Laarhoventwa...@gmail.com wrote:
I would expect that
(id unawait x) await !== unawait x await === return x
There are several type errors in this equation, so I'm not exactly
sure what you mean.
On 2012-03-11 17:30, Mario Blažević wrote:
It's difficult to say without having the implementation of both unawait and all
the combinators in one package. I'll assume the following equations hold:
unawait x await = return x
unawait x yield y = yield y unawait x
(p1 unawait x) p2 = (p1 p2)
On Sun, Mar 11, 2012 at 2:33 PM, Twan van Laarhoven twa...@gmail.com wrote:
I think you should instead move unwaits in and out of the composition on the
left side:
unawait x (p1 + p2) === (unawait x p1) + p2
This makes idP a left-identity for (+), but not a right-identity, since
you
On 12-03-11 01:36 PM, Chris Smith wrote:
On Sun, Mar 11, 2012 at 11:22 AM, Mario Blaževićblama...@acanac.net wrote:
No, idP does terminate once it consumes its input. Your idP p first
reproduces the complete input, and then runs p with empty input.
This is just not true. idP consumes
On Sun, Mar 11, 2012 at 8:53 PM, Mario Blažević blama...@acanac.net wrote:
May I enquire what was the reason for the non-termination of idP? Why was
it not defined as 'forP yield' instead? The following command runs the way I
expected.
With pipes-core (which, recall, is known to be
On Sat, Mar 10, 2012 at 4:21 AM, Mario Blažević blama...@acanac.net wrote:
I like your design, it seems to strike a good balance between elegance
and practicality. The only thing missing for the latter is a deeper support
for chunking. Of course, that would probably destroy some of the
On 12-03-10 05:16 AM, Paolo Capriotti wrote:
On Sat, Mar 10, 2012 at 4:21 AM, Mario Blaževićblama...@acanac.net wrote:
I like your design, it seems to strike a good balance between elegance
and practicality. The only thing missing for the latter is a deeper support
for chunking. Of course,
On 2012-03-10 11:16, Paolo Capriotti wrote:
Another issue is how to deal with unconsumed input. For that, there is
a ChunkPipe type (in pipes-extra) with a specialized monad instance
that threads unconsumed input along. You can see an example of
ChunkPipe in action in this prototype http server
On 12-03-10 05:19 PM, Twan van Laarhoven wrote:
On 2012-03-10 11:16, Paolo Capriotti wrote:
Another issue is how to deal with unconsumed input. For that, there is
a ChunkPipe type (in pipes-extra) with a specialized monad instance
that threads unconsumed input along. You can see an example of
On 2012-03-11 00:09, Mario Blažević wrote:
On 12-03-10 05:19 PM, Twan van Laarhoven wrote:
-- | Pass some unconsumed input back upstream.
-- The next @await@ will return this input without blocking.
unawait :: Monad m = a - Pipe a b m ()
The function may be called unawait, but there's nothing
On 12-03-10 09:05 PM, Twan van Laarhoven wrote:
On 2012-03-11 00:09, Mario Blažević wrote:
On 12-03-10 05:19 PM, Twan van Laarhoven wrote:
-- | Pass some unconsumed input back upstream.
-- The next @await@ will return this input without blocking.
unawait :: Monad m = a - Pipe a b m ()
The
I'm pleased to announce the release of version 0.0.1 of pipes-core, a
library for efficient, safe and compositional IO, similar in scope to
iteratees and conduits.
http://hackage.haskell.org/package/pipes-core
This is a reimplementation of the original 'Pipe' concept by Gabriel
Gonzales. The
On 12-03-09 07:36 PM, Paolo Capriotti wrote:
I'm pleased to announce the release of version 0.0.1 of pipes-core, a
library for efficient, safe and compositional IO, similar in scope to
iteratees and conduits.
I like your design, it seems to strike a good balance between
elegance and
26 matches
Mail list logo
