[Haskell-cafe] ANNOUNCE: pipes-core 0.0.1

Paolo Capriotti p.capriotti at gmail.com
Sun Mar 11 14:46:52 CET 2012


On Sun, Mar 11, 2012 at 1:25 PM, Twan van Laarhoven <twanvl at 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 ()
>> yield :: b ->  Pipe a b m ()
>
>
> 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. If you intended to write something like:

(id >>> (unawait x >> return y)) >>> await
    !==
(unawait x >> return y) >>> await

then I disagree, because both sides should evaluate to 'return y'. I'm
not sure why you would expect x to be returned, since there is no
'await' after 'unawait' in the middle pipe.

> because in the general case of
>
>    (p >>> unawait x)
>
> if is impossible to transform the unawaited value out of the composition.

Why? The natual definition would be:

p >+> (unawait x >> p') == (yield x >> p) >+> p'

To
> do that you would need the inverse of p. You can get around this by having a
> special constructor for the identity. But then
>
>    id !== arr id
>
> IMO, neither of these failed laws would be a big problem in practice, since
> no one will actually use identity pipes in combination with unawait.

I'm extremely wary of this sort of reasoning, because failure of
invariants in simple situations are a symptom of something being
conceptually wrong in the abstraction.

> Or perhaps we should be satisfied when Pipe is a Semigroupoid?

I don't think so, since we can always add formal identities. Usually,
though, failure of the identity law implies failure of associativity,
by just putting the "failing identity" in the middle of a composition.

BR,
Paolo



More information about the Haskell-Cafe mailing list